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

[Nancy Winget (ncamwing) (ncamwing]

Hi Mike,

Yes, that makes sense.  Thanks,

        Nancy. 

-----Original Message-----
From: Michael Montemurro [mailto:michael.montemurro [at] siemens.com] 
Sent: Tuesday, March 21, 2006 7:18 AM
To: Nancy Winget (ncamwing); capwap
Subject: RE: [Capwap] DTLS comments, questions and issues
Sensitivity: Personal

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
>