Capwap Mailing List: RE: DTLS comments, questions and issues

[Michael Montemurro (michael.montemurro]

I've created two issues to track these comments:
- Issue 86 refers to edits to the DTLS text in the CAPWAP specification.
- Issue 87 deals with the feature request for securing the data channel with
DTLS.

I think these issues really need to be resolved independently.

Cheers,

        Mike 

> -----Original Message-----
> From: Nancy Winget (ncamwing) [mailto:ncamwing [at] cisco.com] 
> Sent: March 21, 2006 9:59 AM
> To: capwap
> Subject: [Capwap] DTLS comments, questions and issues
> Sensitivity: Personal
> 
> Hi,
> 
> The inclusion of DTLS has not addressed most if any of my 
> initial comments when it was a standalone draft. Beyond the 
> comments I'd provided previously against the 
> draft-kelly-capwap-lwapp-dtls draft, I have a few more to add 
> (though I stopped once I realized that most of my original 
> comments stand as well):
> 
> * The draft now states that DTLS can optionally be used to 
> protect datagrams.  This is quite surprising as I do not 
> recall this being discussed in great depth.  If it is to be 
> considered, and since the data plane is in a separate port, I 
> would assume that 2 (D)TLS sessions may be required?  If not, 
> how will the sequence number in or anti-replay detection 
> mechanism of DTLS be maintained for both control and data planes?
> 
> * 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? 
> 
>       Nancy
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
> 
> Archives: http://lists.frascone.com/pipermail/capwap
>