| Re: Issue 30: Inconsistent state tracking on AC prior toDTLSEstablishment | <– Date –> <– Thread –> |
From: Scott G. Kelly (s.kelly ix.netcom.com)
|
|
| Date: Sun, 16 Dec 2007 07:59:55 -0800 (PST) | |
Comments inline below... -----Original Message----- >From: Charles Clancy <clancy [at] cs.umd.edu> >Sent: Dec 15, 2007 2:52 PM >To: capwap <capwap [at] frascone.com> >Subject: Re: [Capwap] Issue 30: Inconsistent state tracking on AC prior >toDTLSEstablishment > >I'm trying to compare Pat and Scott's suggested changes. Scott is >suggesting removing (f) and adding a new transition from discovery to >idle (at least those would be necessary for your proposed text to make >sense). Pat is also suggesting doing that, but is also suggesting some >additional changes that deal with further separation of a logical global >state machine in the AC and per-WTP state machines (by adding the "Dead" >state and a rearranging a few more state transitions). I think I confused things by suggesting idle-discovery-idle transitions for the AC. I originally suggested (in an offline email to you guys last week) that the discovery-idle-sulk loop does not exist for the AC, and you said the same thing in your email that Pat cut/pasted to the issue tracker. That is what I should have said in this thread as well. If one really wishes to show a discovery "state" for the AC (which does not make sense, since the AC is stateless with respect to discovery), then a simple loop from discovery to discovery is all that is required to reflect the "transition" that occurs when the AC receives a discovery request, sends a response, and goes back to listening. That is, there is no idle state, and no idle<->discovery transitions. >I think there are problems in the state machine if we only patch the >idle/discovery transitions, as suggested by Scott. In particular, >there's no way to throttle failed DTLS connections when no discovery is >performed (the only error exit from DTLS Setup is to Idle -- we need a >way to get from DTLS Setup to sulking to prevent repeated crypto >failures from causing Idle->DTLSSetup->Idle loops). > >I'm not seeing Scott's issues with the new state machine (i.e. the "new >problems and confusion"). The discovery-idle-sulking changes seem >logically identical between the two proposals. If there are text >issues, I think those can be sorted out. > >I think Scott's suggestions could work, but would need some additional >transitions (i.e. DTLS Setup to Sulking for the WTP, among others) to >make everything work right. One of us is missing something - let me know if it's me. My understanding is that issue 30 refers to the AC only, but you are talking about the WTP here. I made no suggestions regarding the WTP, and as far as I can tell, neither did Pat. Sulking, as currently defined, should *never* occur on the AC - it creates an easy opportunity for unauthenticated, low cost DoS attacks of measurable duration (due to the sulking period). This makes it really easy to send "pulses" every (sulk_period - n seconds) which can take and keep legitimate WTPs offline. It makes no sense to design this flaw into the protocol. If implementations want to deal with this at the AC (other than sending an administrative alert), rate limiting with random packet drops is far more sensible, and mitigates any effect on legitimate WTPs. >Whether Pat's changes are too drastic -- I guess that's for the WG to >decide. I do think Pat has a complete set of changes that solve all the >issues raised in issue 30. The need for discovery transitions, a "dead state", etc. derive from a red herring, because discovery is stateless for the AC. I'm really surprised you helped Pat design these state machine changes, after saying pretty much the same things I say above in your response to his issuer tracker post. Was there some compelling argument that changed your mind? If so, please share it - I am not intransigent in my position, but from what I can see, what you guys are proposing makes no sense, and only serves to make the state machine in the document conform to an implementation which maintains discovery state. --Scott > >-- >t. charles clancy, ph.d. eng.umd.edu/~tcc >electrical & computer engineering, university of maryland > >Pat Calhoun (pacalhou) wrote: >> The reason why I like the new state machine is that it is very clear on >> how the AC deals with the fact that it keeps multiple copies of state >> machine context. The previous version really didn't make that clear at >> all. As an implementer, I know that I just have to follow the >> guidelines, which clearly state when a copy is made, and managed >> independently, and when it is deleted. >> >> I recognize this provides some implementation guidance, and some folks >> don't like that. But it certainly is clear. >> >> If the issue has to do with the Sulking state, then we can address that. >> I would, however, be interested in Charles' take on that issue. >> >> PatC >> >> -----Original Message----- >> From: Scott Kelly [mailto:skelly [at] arubanetworks.com] >> Sent: Wednesday, December 12, 2007 9:17 AM >> To: Pat Calhoun (pacalhou); capwap >> Subject: RE: [Capwap] Issue 30: Inconsistent state tracking on AC prior >> toDTLSEstablishment >> >> We've had a private discussion on this topic off-list, but have not been >> able to come to agreement, so I'll make my comments here. I don't think >> we should (or need to) introduce these dramatic changes to the document >> just prior to last call. >> >> The "problem" we are trying to resolve resulted when someone added >> language saying the AC MAY maintain discovery state. This change was >> apparently introduced last January. There is no record of working group >> or mailing list discussion -- the change just appeared in a document >> update. >> >> On Oct 12, Pat posted a comment saying the state machine language >> surrounding discovery state is inconsistent. I agree. It was made >> inconsistent by the introduction of discovery state to the AC. >> >> In the issue tracker, there is a comment from Charles which must have >> been copied from a private email, as I cannot find it in the list >> archives. Here is that comment: >> >> ---------------------------------------------- >> It seems to me that to be in any state at all assumes state is being >> maintained. Describing a transition from one state to another with >> behavior caveatted with "if state is being maintained" doesn't make any >> sense to me. >> If we have no state, then we have no state transitions. >> >> IIRC, don't we allow connections that don't do discovery first (it's >> been a while, correct me if I'm wrong)? In which case, DTLS on the AC >> should always be listening, and transition "f" can be simply a WTP >> transition. The AC >> >> transition would be back to Idle rather than DTLS setup. You could run >> discovery as its own subgraph of the AC state machine. If you wanted to >> share state information between the two, you could have an API to do >> that. >> ------------------------------------------------ >> >> I agree with what Charles says above. >> >> The changes Pat is proposing do not fix the problem - they actually >> introduce new problems and confusion. Since we have agreed that the AC >> SHOULD NOT maintain discovery state, the discovery-idle-sulking >> transitions make no sense in the context of the AC. However, fixing this >> does not require separate state machines, or dramatic changes to the >> existing state machine. >> >> In draft-08, section 2.3, just below Figure 3, it says "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 implemented in one >> or the other of the AC or WTP), this is explicitly called out in the >> transition descriptions below." >> >> This implies that we just need to make sure the state machine language >> around AC discovery processing is clear. We can do this by adopting >> three simple changes recommended in Pat's text below (with minor edits): >> >> For Idle-to-Discovery it should say: >> >> AC: This state transition is executed by the AC >> when a Discovery Request message is >> received. The AC SHOULD respond with a Discovery Response >> message (see Section 5.2). The AC SHOULD NOT maintain WTP >> state at this point (see Section 12 for more information). >> >> For Discovery to Idle it should say: >> >> AC: This state transition is executed by the AC after processing >> a Discovery Request. >> >> For Discovery to Sulking it says: >> AC: This is an invalid state transition for the AC. >> >> >> With these simple changes, the problem is solved. >> >> --Scott >> >>> -----Original Message----- >>> From: Pat Calhoun (pacalhou) [mailto:pcalhoun [at] cisco.com] >>> Sent: Tuesday, December 04, 2007 3:28 PM >>> To: capwap >>> Subject: Re: [Capwap] Issue 30: Inconsistent state tracking on AC >>> prior toDTLSEstablishment >>> >>> All, >>> >>> I wanted to send the new state machine in order to get as many eyes on >> >>> this one as possible. I have done what I believe is a very thorough >>> review, but this is a complex state machine. I will also include all >>> of the state machine text in order to make it simpler to review. >>> Note that >>> other than the teardown, no changes were made from the join/config >>> states on (meaning, only the lower part of the state machine figure >>> was modified). >>> >>> Since there is significant text here, I want to provide a little bit >>> of information on how this now works: >>> - The WTP behaves pretty much the same as before, meaning that it uses >> >>> a single state context. When a connection attempt fails, the state >>> machine goes back to the Idle state, unless some counters have hit a >>> threshold, in which case the state transitions to the Sulking state. >>> As before the WTP can do the Discovery phase, in which case either >>> state >>> (5) or (c) is >>> used. >>> - The AC now defines two separate threads; Listener and Service. The >>> Listener is the main thread that handles the discovery messages. Once >>> a connection request is received, it spawns a Service thread to deal >>> with the WTP. You will notice that the new state machine uses numerals >> >>> when it applies either only to the WTP, or to the Listener thread. >>> All state >>> transitions that use alphabetic, or symbols, is for the Service thread >> >>> or the WTP. The biggest difference in how the state machines work is >>> that on the AC, when a connection is being established, and fails, the >> >>> Service thread's state moves back to the DTLS Setup state, not Idle. >>> When the error thresholds are hit, the state moves to Sulking - the >>> quiet period. You will also notice a new Dead state, which is ONLY >>> valid for the Service thread, which is where the thread is terminated, >> >>> and resources are freed. >>> >>> Comments welcomed, >>> >>> PatC >>> >>> >>> <text> >>> 2.3. CAPWAP State Machine Definition >>> >>> The following state diagram represents the lifecycle of a WTP-AC >>> session. Use of DTLS by the CAPWAP protocol results in the >>> juxtaposition of two nominally separate yet tightly bound state >>> machines. The DTLS and CAPWAP state machines are coupled through >>> an >>> 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 >>> are triggered by commands from the CAPWAP state machine, while >>> certain transitions in the CAPWAP state machine are triggered by >>> notifications from the DTLS state machine. >>> >>> /-------------------------------------\ >>> | /-------------------------\| >>> | w| || >>> | x+----------+ y +------------+ || >>> | | Run |-->| Reset |-\|| >>> | +----------+ +------------+ ||| >>> u| V ^ ^ ^ z||| >>> +------------+--------/ | | ||| >>> | Data Check | /-------/ | ||| >>> +------------+<-------\ | | ||| >>> | | | ||| >>> /------------------+--------\ | ||| >>> m| t| o| q v r| ||| >>> +--------+ +-----------+ +--------------+||| >>> | Join |---->| Configure | | Image Data |||| >>> +--------+ n +-----------+ +--------------+||| >>> ^ |l p| s| ||| >>> | | \-------------------\ | ||| >>> | \--------------------------------------\| | ||| >>> \------------------------\ || | ||| >>> /--------------<----------------+---------------\ || | ||| >>> | /------------<----------------+-------------\ | || | ||| >>> | | i |k 8| | vv v vvv >>> | | d+----------------+<--+--------------+ +-----------+ >>> /-|-|---| DTLS Setup | | DTLS Connect |-->| DTLS TD | >>> | | | +----------------+e +--------------+ 7 +-----------+ >>> | | | 6| ^ ^ |f ^ j| ^ |~ >>> v v v | | | | | | | | >>> | | | | | | \-------\ | /----+------/ | >>> | | | | | | | | | \---\ | >>> | | | v c| 1 |5 2 v |g |h v v >>> | | \->+------+-->+------+ +-----------+ +--------+ >>> | | | Idle | | Disc | | Authorize | | Dead | >>> | | +------+<--+------+ +-----------+ +--------+ >>> | | ^ 0 |3 ^ >>> | | | | |b >>> | |9 |4 | | >>> | \->+---------+<------/ | >>> \--->| Sulking |----------------------------------/ >>> +---------+ >>> a >>> >>> Figure 3: CAPWAP Integrated State Machine >>> >>> 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 >>> implemented in one or the other of the AC or WTP), this is >>> explicitly >>> called out in the transition descriptions below. For every state >>> >>> defined, only certain messages are permitted to be sent and >>> received. >>> The CAPWAP control messages definitions specify the >>> state(s) in which >>> each message is valid. >>> >>> 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 two 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 the shared >>> services, which includes receiving and responding to Discovery >>> Requests. The Listener thread handles the common tasks, up to >>> the >>> DTLS Setup state. The state machine transitions in the above >>> figure are represented by numerals. >>> >>> Service Thread - The AC's Service thread handles the per WTP >>> states, and one such thread exists per WTP connection. This >>> thread starts during the DTLS Setup state, which is when the >>> DTLSListen command is invoked. 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. The state machine transitions in the >>> above >>> figure are represented by alphabetic characters (including >>> symbols). >>> >>> 2.3.1. CAPWAP Protocol State Transitions >>> >>> This section describes the various state transitions, and the >>> events >>> that cause them. This section does not discuss interactions >>> between >>> DTLS- and CAPWAP-specific states. Those interactions, and DTLS- >>> specific states and transitions, are discussed in Section 2.3.2. >>> >>> Idle to Discovery (1): This transition occurs once device >>> initialization is complete. >>> >>> 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 Listener >>> thread, and occurs when a Discovery Request message is >>> received. The AC SHOULD respond with a Discovery Response >>> message (see Section 5.2). The AC SHOULD NOT maintain WTP >>> state at this point (see Section 12 for more information). >>> >>> Discovery to Discovery (2): In the Discovery state, the WTP >>> determines which AC to connect to. >>> >>> WTP: This transition occurs when the DiscoveryInterval timer >>> expires. If the WTP is configured with a list of ACs, it >>> transmits a Discovery Request message to every AC from which >>> it >>> has not received a Discovery Response message. For every >>> transition to this event, the WTP increments the >>> DiscoveryCount >>> counter. See Section 5.1 for more information on how the WTP >>> knows the ACs to which it should transmit the Discovery >>> Request >>> messages. The WTP restarts the DiscoveryInterval timer >>> whenever it transmits Discovery Request messages. >>> >>> AC: This is an invalid state transition for the AC. >>> >>> Discovery to Idle (0): This transition occurs on the AC's Listener >>> 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 Listener >>> thread >>> when it has transmitted the Discovery Response, in response >>> to >>> a Discovery Request. >>> >>> Discovery to Sulking (3): This transition occurs on a WTP when AC >>> Discovery fails. >>> >>> WTP: The WTP enters this state when the DiscoveryInterval timer >>> expires and the DiscoveryCount variable is equal to the >>> MaxDiscoveries variable (see Section 4.8). Upon entering >>> this >>> state, the WTP MUST start the SilentInterval timer. While in >>> the Sulking state, all received CAPWAP protocol messages >>> received MUST be ignored. >>> >>> AC: This is an invalid state transition for the AC. >>> >>> Sulking to Idle (4): This transition occurs on a WTP when it must >>> restart the discovery phase. >>> >>> WTP: The WTP enters this state when the SilentInterval timer >>> (see >>> Section 4.7) expires. The FailedDTLSSessionCount, >>> DiscoveryCount and FailedDTLSAuthFailCount counters are reset >>> to zero. >>> >>> AC: This is an invalid state transition for the AC. >>> >>> Sulking to Sulking (a): The Sulking state provides the silent >>> period, minimizing the possibility for Denial of Service (DoS) >>> attacks. >>> >>> WTP: All packets received from the AC while in the sulking >>> state >>> are ignored. >>> >>> AC: All packets receive from the WTP on the AC's Service >>> thread, >>> while in the sulking state, are ignored. >>> >>> Sulking to Dead (b): This transition occurs on the AC when the >>> quiet >>> period expires. >>> >>> WTP: This is an invalid state transition for the WTP. >>> >>> AC: The AC enters this state when the SilentInterval timer (see >>> Section 4.7) expires. The AC must clean up all resources >>> associated with the control plane DTLS session. The data >>> plane >>> DTLS session is also shutdown, and all resources freed, 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. >>> >>> Idle to DTLS Setup (c): 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: The AC initiates this transition by invoking the DTLSListen >>> command (see Section 2.3.2.1), which informs the DTLS stack >>> that it is willing to listen for an incoming session. The >>> AC's >>> 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). In such >>> instances, >>> the AC MUST ensure that this state information is freed after >> >>> a >>> period, which is implementation specific. >>> >>> Discovery to DTLS Setup (5): This transition occurs to establish a >>> secure DTLS session with the peer. >>> >>> WTP: The WTP initiates this transition by invoking the >>> DTLSStart >>> command (see Section 2.3.2.1), which starts the DTLS session >>> establishment with the chosen AC. The decision of which AC >>> to >>> connect to is the result of the discovery phase, which is >>> described in Section 3.3. >>> >>> AC: This is an invalid state transition for the AC. >>> >>> DTLS Setup to Idle (6): This transition occurs when the DTLS >>> connection setup has failed. >>> >>> WTP: The WTP initiates this state transition when it receives a >>> DTLSEstablishFail notification from DTLS (see Section >>> 2.3.2.2), >>> and the FailedDTLSSessionCount or the FailedDTLSAuthFailCount >>> counter have not reached the value of the >>> MaxFailedDTLSSessionRetry variable (see Section 4.8). This >>> error notification aborts the secure DTLS session >>> establishment. When this notification is received, the >>> FailedDTLSSessionCount counter is incremented. >>> >>> AC: This is an invalid state transition for the AC. >>> >>> DTLS Setup to Sulking (d): This transition occurs when repeated >>> attempts to setup the DTLS connection have failed. >>> >>> WTP: The WTP enters this state when the FailedDTLSSessionCount >>> or >>> the FailedDTLSAuthFailCount counter reaches the value of the >>> MaxFailedDTLSSessionRetry variable (see Section 4.8). Upon >>> entering this state, the WTP MUST start the SilentInterval >>> timer. While in the Sulking state, all received CAPWAP and >>> DTLS protocol messages received MUST be ignored. >>> >>> AC: The AC enters this state with the specific WTP when the >>> FailedDTLSSessionCount or the FailedDTLSAuthFailCount counter >>> reaches MaxFailedDTLSSessionRetry variable (see Section 4.8). >>> Upon entering this state, the AC's Service thread MUST start >>> the SilentInterval timer, and ignore all CAPWAP and DTLS >>> protocol messages received from the WTP. The AC immediately >>> transitions the state to Idle. >>> >>> DTLS Setup to DTLS Setup (e): This transition occurs when the DTLS >>> Session failed to be established. >>> >>> WTP: This is an invalid state transition for the WTP. >>> >>> AC: The AC initiates this state transition by the Service >>> thread >>> 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. >>> >>> DTLS Setup to Authorize (f): 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 occurs when the AC receives the >>> DTLSPeerAuthorize notification (see Section 2.3.2.2). Upon >>> entering this state, the AC 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 >>> DTLS stack that the session should be established. >>> >>> WTP: This state transition occurs when the WTP has successfully >>> authorized the AC's credentials (see Section 2.4.4). This is >>> done by invoking the DTLSAccept DTLS command (see >>> Section 2.3.2.1). >>> >>> AC: This state transition occurs when the AC has successfully >>> authorized the WTP's credentials (see Section 2.4.4). This >>> is >>> done by invoking the DTLSAccept DTLS command (see >>> Section 2.3.2.1). >>> >>> Authorize to DTLS Teardown (h): This transition occurs to notify >>> the >>> DTLS stack that the session should be aborted. >>> >>> WTP: This state transition occurs when the WTP was unable to >>> authorize the AC, using the AC credentials. The WTP then >>> aborts the DTLS session by invoking the DTLSAbortSession >>> command (see Section 2.3.2.1). >>> >>> AC: This state transition occurs when the AC was unable to >>> authorize the WTP, using the WTP credentials. The AC then >>> aborts the DTLS session by invoking the DTLSAbortSession >>> command (see Section 2.3.2.1). >>> >>> 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 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 >>> DTLSAborted or DTLSAuthenticateFail notification (see >>> Section 2.3.2.2), indicating that the DTLS session was not >>> successfully established, and both of the >>> FailedDTLSAuthFailCount and FailedDTLSSessionCount counters >>> have not reached the value of the MaxFailedDTLSSessionRetry >>> variable (see Section 4.8). >>> >>> 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). >>> >>> DTLS Connect to Join (k): This transition occurs when the DTLS >>> Session is successfully established. >>> >>> WTP: This state transition occurs when the WTP receives the >>> DTLSEstablished notification (see Section 2.3.2.2), >>> indicating >>> that the DTLS session was successfully established. >>> When this >>> notification is received, the FailedDTLSSessionCount counter >>> is >>> set to zero. >>> >>> AC: This state transition occurs when the AC receives the >>> DTLSEstablished notification (see Section 2.3.2.2), >>> indicating >>> that the DTLS session was successfully established. >>> When this >>> notification is received, the FailedDTLSSessionCount counter >>> is >>> set to zero, and the WaitJoin timer is started (see >>> Section 4.7). >>> >>> Join to DTLS Teardown (l): This transition occurs when the join >>> process failed. >>> >>> WTP: This state transition occurs when the WTP receives a Join >>> Response message with a Result Code message element >>> containing >>> an error, if the Image Identifier provided by the AC in the >>> Join Response message differs from the WTP's currently >>> running >>> firmware version and the WTP has the requested image in its >>> non-volatile memory, or if the WaitDTLS timer expires. This >>> causes the WTP to initiate the DTLSShutdown command (see >>> Section 2.3.2.1). This transition also occurs if the WTP >>> receives one of the following DTLS notifications: >>> DTLSAborted, >>> DTLSReassemblyFailure or DTLSPeerDisconnect. >>> >>> AC: This state transition occurs either if the WaitJoin timer >>> expires or if the AC transmits a Join Response message with a >>> Result Code message element containing an error. This causes >>> the AC to initiate the DTLSShutdown command (see >>> Section 2.3.2.1). This transition also occurs if the AC >>> receives one of the following DTLS notifications: >>> DTLSAborted, >>> DTLSReassemblyFailure or DTLSPeerDisconnect. >>> >>> Join to Image Data (m): This state transition is used by the WTP >>> and >>> the AC to download executable firmware. >>> >>> WTP: The WTP enters the Image Data state when it receives a >>> successful Join Response message and determines and the >>> included Image Identifier message element is not the same as >>> its currently running image. The WTP also detects that the >>> requested image version is not currently available in the >>> WTP's >>> non-volatile storage (see Section 9.1 for a full description >>> of >>> the firmware download process). The WTP initializes the >>> EchoInterval timer (see Section 4.7), and transmits the Image >>> Data Request message (see Section 9.1.1) requesting the start >>> of the firmware download. >>> >>> AC: This state transition occurs when the AC receives the Image >>> Data Request message from the WTP. The AC MUST transmit an >>> Image Data Response message (see Section 9.1.2) to the WTP, >>> which includes a portion of the firmware. The AC MUST start >>> the ImageDataStartTimer timer (see Section 4.7). >>> >>> Join to Configure (n): This state transition is used by the WTP >>> and >>> the AC to exchange configuration information. >>> >>> WTP: The WTP enters the Configure state when it receives a >>> successful Join Response, and determines that the included >>> Image Identifier message element is the same as its currently >>> running image. The WTP transmits the Configuration Status >>> message (see Section 8.2) to the AC with message elements >>> describing its current configuration. The WTP also starts >>> the >>> ResponseTimeout timer (see Section 4.7). >>> >>> AC: This state transition occurs immediately after the AC >>> transmits the Join Response message to the WTP. If the AC >>> receives the Configuration Status message from the WTP, the >>> AC >>> MUST transmit a Configuration Status Response message (see >>> Section 8.3) to the WTP, and MAY include specific message >>> elements to override the WTP's configuration. The AC also >>> starts the ChangeStatePendingTimer timer (see Section 4.7). >>> >>> Configure to Reset (o): This state transition is used to reset the >>> connection either due to an error during the configuration >>> phase, >>> or when the WTP determines it needs to reset in order for the >>> new >>> configuration to take effect. >>> >>> WTP: The WTP enters the Reset state when it receives a >>> Configuration Status Response indicating an error or when it >>> determines that a reset of the WTP is required, due to the >>> characteristics of a new configuration. >>> >>> AC: The AC transitions to the Reset state when it receives a >>> Change State Event message from the WTP that contains an >>> error >>> for which AC policy does not permit the WTP to provide >>> service. >>> This state transition also occurs when the AC >>> ChangeStatePendingTimer timer expires. >>> >>> Configure to DTLS Teardown (p): This transition occurs when the >>> configuration process aborts due to a DTLS error. >>> >>> WTP: The WTP enters this state when it receives one of the >>> following DTLS notifications: DTLSAborted, >>> DTLSReassemblyFailure or DTLSPeerDisconnect (see >>> Section 2.3.2.2). The WTP MAY tear down the DTLS session if >>> it >>> receives frequent DTLSDecapFailure notifications. >>> >>> AC: The AC enters this state when it receives one of the >>> following DTLS notifications: DTLSAborted, >>> DTLSReassemblyFailure or DTLSPeerDisconnect (see >>> Section 2.3.2.2). The WTP MAY tear down the DTLS session if >>> it >>> receives frequent DTLSDecapFailure notifications. >>> >>> Image Data to Image Data (q): The Image Data state is used by the >>> WTP and the AC during the firmware download phase. >>> >>> WTP: The WTP enters the Image Data state when it receives an >>> Image Data Response message indicating that the AC has more >>> data to send. >>> >>> AC: This state transition occurs when the AC receives the Image >>> Data Request message from the WTP while already in the Image >>> Data state. The AC resets the ImageDataStartTimer timer. >>> >>> Image Data to Reset (r): This state transition is used to reset >>> the >>> DTLS connection prior to restarting the WTP after an image >>> download. >>> >>> WTP: When an image download completes, the WTP enters the Reset >>> state. The WTP MAY also transition to this state upon >>> receiving an Image Data Response message from the AC (see >>> Section 9.1.2) indicating a failure. >>> >>> AC: The AC enters the Reset state when an error occurs during >>> the >>> image download process or if the ImageDataStartTimer timer >>> expires. >>> >>> Image Data to DTLS Teardown (s): This transition occurs when the >>> firmware download process aborts due to a DTLS error. >>> >>> WTP: The WTP enters this state when it receives one of the >>> following DTLS notifications: DTLSAborted, >>> DTLSReassemblyFailure or DTLSPeerDisconnect (see >>> Section 2.3.2.2). The WTP MAY tear down the DTLS session if >>> it >>> receives frequent DTLSDecapFailure notifications. >>> >>> AC: The AC enters this state when it receives one of the >>> following DTLS notifications: DTLSAborted, >>> DTLSReassemblyFailure or DTLSPeerDisconnect (see >>> Section 2.3.2.2). The WTP MAY tear down the DTLS session if >>> it >>> receives frequent DTLSDecapFailure notifications. >>> >>> Configure to Data Check (t): This state transition occurs when the >>> WTP and AC confirm the configuration. >>> >>> WTP: The WTP enters this state when it receives a successful >>> Configuration Status Response message from the AC. The WTP >>> initializes the EchoInterval timer (see Section 4.7), and >>> transmits the Change State Event Request message (see >>> Section 8.6). >>> >>> AC: This state transition occurs when the AC receives the >>> Change >>> State Event Request message (see Section 8.6) from the WTP. >>> The AC responds with a Change State Event Response message >>> (see >>> Section 8.7). The AC MUST start the DataCheckTimer timer >>> (see >>> Section 4.7). >>> >>> Data Check to DTLS Teardown (u): This transition occurs when the >>> WTP >>> does not complete the Data Check exchange. >>> >>> WTP: This state transition occurs if the WTP does not receive >>> the >>> Change State Event Response before a CAPWAP transmission >>> timeout occurs. >>> >>> AC: The AC enters this state when the DataCheckTimer timer >>> expires (see Section 4.7). >>> >>> Data Check to Run (V): This state transition occurs when the >>> linkage >>> between the control and data channels has occured, causing the >>> WTP >>> and AC to enter their normal state of operation. >>> >>> WTP: The WTP enters this state when it receives a successful >>> Change State Event Response message from the AC. The WTP >>> initiates the data channel, which MAY require the >>> establishment >>> of a DTLS session, starts the DataChannelKeepAlive timer (see >>> Section 4.7) and transmits a Data Channel Keep Alive packet >>> (see Section 4.4.1). The WTP then starts the >>> DataChannelDeadInterval timer (see Section 4.7). >>> >>> AC: This state transition occurs when the AC receives the Data >>> Channel Keep Alive packet (see Section 4.4.1), with a Session >>> ID message element matching that included by the WTP in the >>> Join Request message. The AC disables the DataCheckTimer >>> timer. Note that if AC policy is to require the data channel >>> to be encrypted, this process would also require the >>> establishment of a data channel DTLS session. Upon receiving >>> the Data Channel Keep Alive packet, the AC transmits its own >>> Data Channel Keep Alive packet. >>> >>> Run to DTLS Teardown (w): This state transition occurs when an >>> error >>> has occured in the DTLS stack, causing the DTLS session to be >>> torndown. >>> >>> WTP: The WTP enters this state when it receives one of the >>> following DTLS notifications: DTLSAborted, >>> DTLSReassemblyFailure or DTLSPeerDisconnect (see >>> Section 2.3.2.2). The WTP MAY tear down the DTLS session if >>> it >>> receives frequent DTLSDecapFailure notifications. >>> The WTP also >>> transitions to this state if the underlying reliable >>> transport's RetransmitCount counter has reached the >>> MaxRetransmit variable (see Section 4.7). >>> >>> AC: The AC enters this state when it receives one of the >>> following DTLS notifications: DTLSAborted, >>> DTLSReassemblyFailure or DTLSPeerDisconnect (see >>> Section 2.3.2.2). The WTP MAY tear down the DTLS session if >>> it >>> receives frequent DTLSDecapFailure notifications. The AC >>> transitions to this state if the underlying reliable >>> transport's RetransmitCount counter has reached the >>> MaxRetransmit variable (see Section 4.7). >>> >>> Run to Run (x): This is the normal state of operation. >>> >>> WTP: This is the WTP's normal state of operation. >>> There are many >>> events that result this state transition: >>> >>> Configuration Update: The WTP receives a Configuration >>> Update >>> Request message(see Section 8.4). The WTP MUST respond >>> with >>> a Configuration Update Response message (see Section 8.5). >>> >>> Change State Event: The WTP receives a Change State Event >>> Response message, or determines that it must initiate a >>> Change State Event Request message, as a result of a >>> failure >>> or change in the state of a radio. >>> >>> Echo Request: The WTP sends an Echo Request message >>> (Section 7.1) or receives the corresponding Echo Response >>> message, (see Section 7.2) from the AC. >>> >>> Clear Config Request: The WTP receives a Clear Configuration >>> Request message (see Section 8.8). The WTP MUST reset its >>> configuration back to manufacturer defaults. >>> >>> WTP Event: The WTP sends a WTP Event Request message, >>> delivering information to the AC (see Section 9.4). The >>> WTP >>> receives a WTP Event Response message from the AC (see >>> Section 9.5). >>> >>> Data Transfer: The WTP sends a Data Transfer Request message >>> to the AC (see Section 9.6). The WTP receives a Data >>> Transfer Response message from the AC (see Section 9.7). >>> >>> Station Configuration Request: The WTP receives a Station >>> Configuration Request message (see Section 10.1), to which >>> it MUST respond with a Station Configuration Response >>> message (see Section 10.2). >>> >>> AC: This is the AC's normal state of operation: >>> >>> Configuration Update: The AC sends a Configuration Update >>> Request message (see Section 8.4) to the WTP to update its >>> configuration. The AC receives a Configuration Update >>> Response message (see Section 8.5) from the WTP. >>> >>> Change State Event: The AC receives a Change State Event >>> Request message (see Section 8.6), to which it MUST >>> respond >>> with the Change State Event Response message (see >>> Section 8.7). >>> >>> Echo Request: The AC receives an Echo Request message (see >>> Section 7.1), to which it MUST respond with an Echo >>> Response >>> message(see Section 7.2). >>> >>> Clear Config Response: The AC receives a Clear Configuration >>> Response message from the WTP (see Section 8.9). >>> >>> WTP Event: The AC receives a WTP Event Request message from >>> the WTP (see Section 9.4) and MUST generate a >>> corresponding >>> WTP Event Response message (see Section 9.5). >>> >>> Data Transfer: The AC receives a Data Transfer Request >>> message >>> from the WTP (see Section 9.6) and MUST generate a >>> corresponding Data Transfer Response message (see >>> Section 9.7). >>> >>> Station Configuration Request: The AC sends a Station >>> Configuration Request message (see Section 10.1) or >>> receives >>> the corresponding Station Configuration Response message >>> (see Section 10.2) from the WTP. >>> >>> Run to Reset (y): This state transition is used when either the AC >>> or WTP tear down the connection. This may occur as part of >>> normal >>> operation, or due to error conditions. >>> >>> WTP: The WTP enters the Reset state when it receives a Reset >>> Request message from the AC. >>> >>> AC: The AC enters the Reset state when it transmits a Reset >>> Request message to the WTP. >>> >>> Reset to DTLS Teardown (z): This transition occurs when the CAPWAP >>> reset is complete, to terminate the DTLS session. >>> >>> WTP: This state transition occurs when the WTP receives a Reset >>> Response message. This causes the WTP to initiate the >>> DTLSShutdown command (see Section 2.3.2.1). >>> >>> AC: This state transition occurs when the AC transmits a Reset >>> Response message. The AC does not invoke the DTLSShutdown >>> command (see Section 2.3.2.1). >>> >>> DTLS Teardown to Idle (8): This transition occurs when the DTLS >>> session has been shutdown. >>> >>> WTP: This state transition occurs when the WTP has successfully >>> cleaned up all resources associated with the control plane >>> DTLS >>> session. The data plane DTLS session is also shutdown, and >>> all >>> resources freed, if a DTLS session was established for the >>> data >>> plane. Any timers set for the current instance of the state >>> machine are also cleared. >>> >>> AC: This is an invalid state transition for the AC. >>> >>> DTLS Teardown to Sulking (9): This transition occurs when repeated >>> attempts to setup the DTLS connection have failed. >>> >>> WTP: The WTP enters this state when the FailedDTLSSessionCount >>> or >>> the FailedDTLSAuthFailCount counter reaches the value of the >>> MaxFailedDTLSSessionRetry variable (see Section 4.8). Upon >>> entering this state, the WTP MUST start the SilentInterval >>> timer. While in the Sulking state, all received CAPWAP and >>> DTLS protocol messages received MUST be ignored. >>> >>> AC: This is an invalid state transition for the AC. >>> >>> DTLS Teardown to Dead (~): This transition occurs when the DTLS >>> session has been shutdown. >>> >>> WTP: This is an invalid state transition for the WTP. >>> >>> AC: This state transition occurs when the AC has successfully >>> cleaned up all resources associated with the control plane >>> DTLS >>> session. The data plane DTLS session is also shutdown, and >>> all >>> resources freed, 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. >>> >>> 12.3. Discovery Attacks >>> [...] >>> Some implementations may wish to pass information about clients who >>> have passed the discovery phase to the DTLS layer, 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. As a result, implementations SHOULD >>> NOT maintain state between the discovery and DTLS handshake phases >>> of >>> the CAPWAP protocol initialization. >>> >>> </text> >>> >>> PatC >>> -----Original Message----- >>> From: Pat Calhoun (pacalhou) >>> Sent: Tuesday, December 04, 2007 11:17 AM >>> To: capwap >>> Subject: [Capwap] Issue 30: Inconsistent state tracking on AC prior to >> >>> DTLSEstablishment >>> >>> I wanted to provide a follow-up based on the conversation during the >>> meeting yesterday. The issue that is being raised in this issue is >>> that the state machine doesn't really work well on the AC. There is >>> text that states that the AC has a different "state context" per WTP, >>> but right now this would require that the AC maintains state during >>> the discovery, etc. However, we have all agreed that the AC should not >> >>> have to do so. >>> So we agreed that we needed to provide more clarity on the state >>> machine that allows for the AC to provide services such as responding >>> to Discovery Requests, without explicitely maintaining per WTP state. >>> >>> I am working on modifications to the state machine, and expect to have >> >>> this sent to the list later today. >>> >>> PatC >>> _________________________________________________________________ >>> To unsubscribe or modify your subscription options, please visit: >>> http://lists.frascone.com/mailman/listinfo/capwap >>> >>> Archives: http://lists.frascone.com/pipermail/capwap >>> _________________________________________________________________ >>> To unsubscribe or modify your subscription options, please visit: >>> http://lists.frascone.com/mailman/listinfo/capwap >>> >>> Archives: http://lists.frascone.com/pipermail/capwap >>> >> _________________________________________________________________ >> To unsubscribe or modify your subscription options, please visit: >> http://lists.frascone.com/mailman/listinfo/capwap >> >> Archives: http://lists.frascone.com/pipermail/capwap > >_________________________________________________________________ >To unsubscribe or modify your subscription options, please visit: >http://lists.frascone.com/mailman/listinfo/capwap > >Archives: http://lists.frascone.com/pipermail/capwap
-
Re: Issue 30: Inconsistent state tracking on AC prior toDTLSEstablishment Scott G. Kelly, December 16 2007
- Re: Issue 30: Inconsistent state tracking onAC prior toDTLSEstablishment Pat Calhoun (pacalhou), December 16 2007
- Re: Issue 30: Inconsistent state tracking on AC prior toDTLSEstablishment Charles Clancy, December 22 2007
Results generated by Tiger Technologies using MHonArc.