Subject: [Capwap] Issue 86 Comments on DTLS for CAPWAP Protocol: Proposed Resolution

From: "Dorothy Stanley" <[email-masked]>
Date: Thu, 25 May 2006 12:08:43 -0700

All,

Issue 86, copied below, comments on the -00 draft
state machine operation. The updates made to the state machine
in -01 appear to address all of the comments.

Proposed resolution: Close issue 86, noting that the -01 state machine
updates address these comments.

Thanks,

Dorothy

* Discovery to DTLS-Init state description:
  - The AC state reflects that it is a meta state, which is not quite right.
Since there is a DTLS-complete, it is appropriate for the AC to enter this
state as it is initiating a potential connection with the WTP.

* The descriptions for the WTP actions for the DTLS-Init to Idle and DTLS-Init
to Discovery seem too similar.  What is the difference between an unsuccessful
DTLS session establishment and a failed DTLS handshake?
A similar conflict arises in the AC's descriptions.

* The DTLS-Init to DTLS-Complete appears that it implies a successful DTLS
session establishment and should be explicitly stated so....though I am not
sure why there needs to be such a distinction unless a true capture of the
DTLS state machine is warranted and these 2 states do not fully cover.
  - The explanation for WTP and AC needs to clarify how each party knows the
DTLS session is live and is authorized to begin protected traffic.

* Under which conditions does the AC goes from the DTLS-Init to Idle or
Discovery? There's an inconsistancy between the figure and the text.
That is, there are several events within the DTLS conversation at which the AC
may choose to fail and tear down the DTLS conversation.  My suggestion is that
when these fail, they should go back to the Idle state.

* The DTLS-Reset state doesn't seem to make sense or is inconsistant with the
general LWAPP framework.  What does it mean to be in a DTLS-Reset state?  Does
it mean a full DTLS session must be established?
If so, then it is an effective Reset from the overall state machine
standpoint....
  - why does a new configuration warrant a DTLS-Reset?
  - why does an image update warrant a DTLS-Reset?
  - it seems that perhaps for both of the above, the WTP should go back to
Idle or DTLS-Init again.
  - a Run to DTLS-Reset should force a full CAPWAP Reset, so why not merge and
retain the original Reset as is?

* Why does a key refresh in the DTLS warrant a full state transition?
What is implied by a DTLS-Rekey?
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap