Subject: [Capwap] Proposed Resolution to Issue 220 "Ambiguitues with DTLS"/ was Ambiguities with DTLS

From: "Dorothy Stanley" <[email-masked]>
Date: Wed, 4 Oct 2006 11:29:18 -0700

All,

The proposed resolution to Issue 220 is below.

Comments welcome.

Thanks,

Dorothy
----------------------------------------------------------------------------------------------------------------------

1. The current draft seems to be ambiguous with respect to two DTLS items.

 The draft says in the section describing the stat machine transitions:

Idle to Init (Z): This transition indicates the beginning of a DTLS session.

WTP: The state transition is triggered by receipt of the DTLSStart command

from the CAPWAP state machine, and causes the WTP to send a DTLS ClientHello

to the AC.

AC: The state transition is triggered by receipt of the DTLSStart command from

the CAPWAP state machine. The AC starts the WaitJoin timer and awaits

reception of a DTLS ClientHello message.

In the description of transition aa, the draft says:

AC: Upon receipt of a ClientHello message containing a valid cookie, the AC

sets the WaitJoin timer.

These two transitions seem to require "starting" or "setting" the Waitjoin

timer in the AC both before and after the receipt of the ClientHello message.

I believe the text in transition z is correct and should either be reflected

in the description of transition aa, or removed from it to avoid conflict.

Proposed resolution: No change to the description of (aa). The current
text describing

Transition (aa), listed below, does not reference the WaitJoin Timer:

   Idle to Join (aa): This transition occurs when the WTP presents a

      DTLS ClientHello message containing a valid cookie to the AC.

      WTP: This transition is a no-op for the WTP.

      AC: The AC does not maintain state information until the WTP

         presents a DTLS ClientHello message containing a valid cookie.

         Upon receipt of a DTLS ClientHello message containing a valid

         cookie, the AC creates session state and transitions to the

         Join state.

The text in 6.2 though is incorrect in its description of WaitJoin timer
usage. Change from:

   After determining that a WTP should join the AC, the AC creates
   session state containing the WTP address, port and session ID, sets
   the WaitJoin timer for the session, sends the Join Response message
   to the WTP.

   The WTP, receiving a Join Response message checks for success or
   failure.  If the message indicates success, the WTP clears the
   WaitJoin timer for the session and proceeds to the Configure or Image
   Data state.  Otherwise, the WTP enters the CAPWAP reset state,
   resulting in shutdown of the DTLS session.

to

   Upon receipt of the DTLSClientHello, the AC creates
   session state containing the WTP address, port and session ID, sets
   the WaitJoin timer for the session, sends the Join Response message
   to the WTP.

   The WTP, receiving a Join Response message checks for success or
   failure.  If the message indicates success, the WTP clears the
   WaitJoin timer for the session and proceeds to the Configure State.
   Otherwise, the WTP enters the CAPWAP reset state,
   resulting in shutdown of the DTLS session.

Similarly, the text in 6.1 is incorrect in its description of
WaitJoin Timer usage.

Change from:

The Join Request message is used by a WTP to inform an AC that it
   wishes to provide services through the AC.  A Join Request message is
   sent by a WTP after receiving one or more Discovery Responses, and
   completion of DTLS session establishment.  When an AC receives a Join
   Request message it responds with a Join Response message.

   Upon completion of the DTLS handshake (synonymous with DTLS "session
   establishment"), the WTP sends the Join Request message to the AC.
   Upon receipt of the Join Request Message, the AC generates a Join
   Response message and sends it to the WTP, indicating success or
   failure.

   Upon transmission of the Join Request message, the WTP sets the
   WaitJoin timer.  If the Join Response message has not been received
   prior to expiration, the WTP aborts the Join process and transitions
   back to the Discovery state, see Section 2.3.1).  Upon receipt of the
   Join Response message, the WaitJoin timer is deactivated.

   If the AC rejects the Join Request, it sends a Join Response with a
   failure indication then enters the CAPWAP reset state, resulting in
   shutdown of the DTLS session.

   Upon determining which AC to join, the WTP creates session state
   containing the AC address and session ID, creates the Join Request
   message, sets the WaitJoin timer for the session and sends the Join
   Request message to the AC.

to

The Join Request message is used by a WTP to inform an AC that it
   wishes to provide services through the AC.  A Join Request message is
   sent by a WTP after (optionally) receiving one or more Discovery
Responses, and
   completion of DTLS session establishment.  When an AC receives a Join
   Request message it responds with a Join Response message.

   Upon completion of the DTLS handshake (synonymous with DTLS "session
   establishment"), the WTP sends the Join Request message to the AC.
   Upon receipt of the Join Request Message, the AC generates a Join
   Response message and sends it to the WTP, indicating success or
   failure.

   If the AC rejects the Join Request, it sends a Join Response with a
   failure indication then enters the CAPWAP reset state, resulting in
   shutdown of the DTLS session.

2. The draft also says, in the description of transition o, that the WTP should

send DTLSReset to the state machine.  Should this be DTLSShutdown?

Proposed resolution: Yes. Change "DTLSReset" to "DTLSShutdown"

On 9/14/06, Pat Calhoun (pacalhou) <[email-masked]> wrote:
>
> Tracker issue 220 created.
>
> Pat Calhoun
> CTO, Wireless Networking Business Unit
> Cisco Systems
>
>
>
> > -----Original Message-----
> > From: Bob O'Hara (boohara)
> > Sent: Thursday, September 14, 2006 9:22 AM
> > To: [email-masked]
> > Subject: [Capwap] Ambiguities with DTLS
> >
> > The current draft seems to be ambiguous with respect to two
> > DTLS items.
> >
> > The draft says in the section describing the stat machine transitions:
> > Idle to Init (Z): This transition indicates the beginning of
> > a DTLS session.
> >
> > WTP: The state transition is triggered by receipt of the
> > DTLSStart command from the CAPWAP state machine, and causes
> > the WTP to send a DTLS ClientHello to the AC.
> >
> > AC: The state transition is triggered by receipt of the
> > DTLSStart command from the CAPWAP state machine. The AC
> > starts the WaitJoin timer and awaits reception of a DTLS
> > ClientHello message.
> >
> > In the description of transition aa, the draft says:
> > AC: Upon receipt of a ClientHello message containing a valid
> > cookie, the AC sets the WaitJoin timer.
> >
> > These two transitions seem to require "starting" or "setting"
> > the Waitjoin timer in the AC both before and after the
> > receipt of the ClientHello message.  I believe the text in
> > transition z is correct and should either be reflected in the
> > description of transition aa, or removed from it to avoid conflict.
> >
> > The draft also says, in the description of transition o, that
> > the WTP should send DTLSReset to the state machine.  Should
> > this be DTLSShutdown?
> >
> >  -Bob
> >
> > Bob O'Hara
> > Cisco Systems - WNBU
> >
> > Phone:  +1 408 853 5513
> > Mobile: +1 408 218 4025
> >
> > _________________________________________________________________
> > 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