Subject: Re: [Capwap] New Issue 106: WaitJoin may be unnecessary

From: "Yong Zhang" <[email-masked]>
Date: Tue, 1 Jul 2008 13:36:30 -0700

This change is OK for me.

Yong

On Thu, Jun 26, 2008 at 4:53 AM, Pat Calhoun (pacalhou)
<[email-masked]> wrote:
> I believe you may be correct that there is a technical issue.
>
> Originally, the WaitJoin was used to timeout if the WTP did not sent the
> Join Request, or the AC did not send the Join Response. However, when
> DTLS was introduced, we started to rely on the WaitDTLS timer. It seems
> like we've started to rely much more on the WaitDTLS timer in the latter
> drafts, to the point where I believe that we could simply remove the
> WaitJoin timer and have little impact to the state machine.
>
> From what I can tell, the "Join to DTLS Teardown (e)" state transition
> currently triggers if the WaitJoin timer expires, and we would have to
> change this to WaitDTLS instead. Further, the "DTLS Connect to Join (d)"
> state transition would simply need to have its reference to WaitJoin
> removed.
>
> So since it appears as if the WaitDTLS timers are initialized properly,
> the timeout triggers are properly defined, and it is well specified in
> its handling during the Join Request/Response in section 6.1 and 6.2,
> this change would have mimimal impact.
>
> Thoughts?
>
> PatC
>
> -----Original Message-----
> From: Yong Zhang [mailto:[email-masked]]
> Sent: Friday, June 20, 2008 11:19 AM
> To: Pat Calhoun (pacalhou)
> Cc: [email-masked]
> Subject: Re: [Capwap] WaitDTLS/WaitJoin timers
> indraft-ietf-capwap-protocol-specification-10.txt
>
> This info is clear. But in the spec., the WaitDTLS covers the WaitJoin.
> WairDTLS timer is not cleared after the DTLS session is esatblished, but
> it is only cleared after the Join REQ/RESP are received. (6.1/2
> describes this).
>
> Thanks!
>
> Yong
>
> On Fri, Jun 20, 2008 at 10:55 AM, Pat Calhoun (pacalhou)
> <[email-masked]> wrote:
>> The intent for both timers is:
>>
>> WaitDTLS: This timer is used to make sure that the DTLS session is
>> established within the required timeframe. If the DTLS session isn't
>> setup, perhaps because either party is not responding, then the timer
>> will trigger and the state will change.
>>
>> WaitJoin: Once the DTLS session has been established, we need to
>> protect against a WTP that opts to NOT send a Join Request. So in this
>
>> instance, the WaitJoin would trigger, and the state would once more
> change.
>>
>> PatC
>>
>> -----Original Message-----
>> From: Yong Zhang [mailto:[email-masked]]
>> Sent: Friday, June 20, 2008 9:54 AM
>> To: [email-masked]
>> Subject: [Capwap] WaitDTLS/WaitJoin timers
>> indraft-ietf-capwap-protocol-specification-10.txt
>>
>> WaitDTLS by its name should be DTLS session setup related, but this
>> spec. (6.1/2) requires it deactivated after the Join Req/Resp are
>> received.
>>
>> WaitJoin seems no use in this case??
>>
>> Also the WaitDTLS timer is started earlier than WaitJoin timer,
>> however, the default value for these two timers (4.7.15/16) are all
>> 60s. if WaitJoin has some other use, it need to have a less value than
>
>> WaitDTLS to work.
>>
>> Yong
>> _________________________________________________________________
>> 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

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 7 Jul 2008 04:27:45 -0700

All,

Here is the actual text handling this change, which I have reviewed with
Yong and he has responded that he is OK with the change. The AC in the
spec was using the WaitJoin timer, so I had to make a couple of changes
to two state transisions to make sure that the AC was making proper use
of the WaitDTLS timer:

<text>
   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(see Section 2.3.2.1), which starts the DTLS session
         establishment with the chosen AC and the WaitDTLS timer is
         started (see Section 4.7).  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),
         and the WaitDTLS timer is started (see Section 4.7).    <=====
THE TIMER IS STARTED

   Join to DTLS Teardown (e):  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 WaitDTLS timer
<=== THE TIMER EXPIRES
         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.
</text> 

PatC
-----Original Message-----
From: Yong Zhang [mailto:[email-masked]] 
Sent: Tuesday, July 01, 2008 1:37 PM
To: Pat Calhoun (pacalhou)
Cc: [email-masked]
Subject: Re: New Issue 106: WaitJoin may be unnecessary

Yong

On Thu, Jun 26, 2008 at 4:53 AM, Pat Calhoun (pacalhou)
<[email-masked]> wrote:
> Originally, the WaitJoin was used to timeout if the WTP did not sent 
> the Join Request, or the AC did not send the Join Response. However, 
> when DTLS was introduced, we started to rely on the WaitDTLS timer. It

> seems like we've started to rely much more on the WaitDTLS timer in 
> the latter drafts, to the point where I believe that we could simply 
> remove the WaitJoin timer and have little impact to the state machine.
>

> So since it appears as if the WaitDTLS timers are initialized 
> properly, the timeout triggers are properly defined, and it is well 
> specified in its handling during the Join Request/Response in section 
> 6.1 and 6.2, this change would have mimimal impact.
>
> Thoughts?
>
> PatC
>
> WairDTLS timer is not cleared after the DTLS session is esatblished, 
> but it is only cleared after the Join REQ/RESP are received. (6.1/2 
> describes this).
>
> Thanks!
>
> Yong
>

---

From: "Yong Zhang" <[email-masked]>
Date: Mon, 7 Jul 2008 09:52:57 -0700

This is OK. But I found another issue. We did not process the WaitDTLS
timer expire
event in the several DTLS states.

Yong

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 7 Jul 2008 14:47:26 -0700

Got it - and while this information is available in other places in the
spec, it needs to be clear in the FSM state transition descriptions as
well. The change below is to add specific text about the state
transitions occuring when the WaitDTLS timer expires. The last change
below mentions that the WaitDTLS timer is stopped when the 'DTLS Connect
to Join' state transition occurs. This is not new, as it is mentioned in
the Join Request in section 6.1, but having it in the FSM will help
implementors by not needing to find this out only when reading later in
the spec.

<text>
2.3.1.  CAPWAP Protocol State Transitions
[...]
   DTLS Setup to Idle ($):  This transition occurs when the DTLS
      connection setup fails.

      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.  This state
         transition also occurs if the WaitDTLS timer has expired.
[...]
   Authorize to DTLS Teardown (b):  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).  This state transition also
         occurs if the WaitDTLS timer has expired.

      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).  This state transition also
         occurs if the WaitDTLS timer has expired.
[...]
   DTLS Connect to DTLS Teardown (c):  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.  This state
         transition also occurs if the WaitDTLS timer has expired.

      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).  This state transition also occurs
         if the WaitDTLS timer has expired.
[...]
   DTLS Connect to Join (d):  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.  The WTP enters the Join state by transmiting the
         Join Request to the AC.  The WTP stops the WaitDTLS timer.

      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.  The AC stops the WaitDTLS timer. 
</text>

PatC
-----Original Message-----
From: Yong Zhang [mailto:[email-masked]] 
Sent: Monday, July 07, 2008 9:53 AM
To: Pat Calhoun (pacalhou)
Cc: [email-masked]
Subject: Re: New Issue 106: WaitJoin may be unnecessary

This is OK. But I found another issue. We did not process the WaitDTLS
timer expire event in the several DTLS states.

Yong

On Mon, Jul 7, 2008 at 4:27 AM, Pat Calhoun (pacalhou)
<[email-masked]> wrote:
> All,
>
> Here is the actual text handling this change, which I have reviewed 
> with Yong and he has responded that he is OK with the change. The AC 
> in the spec was using the WaitJoin timer, so I had to make a couple of

> changes to two state transisions to make sure that the AC was making 
> proper use of the WaitDTLS timer:
>
> <text>

---

From: "Yong Zhang" <[email-masked]>
Date: Mon, 7 Jul 2008 18:50:42 -0700

On Mon, Jul 7, 2008 at 6:50 PM, Yong Zhang <[email-masked]> wrote:
> This is OK for me.
>
> Yong
>
> On Mon, Jul 7, 2008 at 2:47 PM, Pat Calhoun (pacalhou)