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

[Scott G. Kelly (s.kelly]

I'm going to reply inline below, but I would suggest that if any questions 
remain, we break them out into per-issue threads (to keep the discussions 
coherent and manageable).

Also, for the benefit of those who were not at the working group meeting 
yesterday,  we noted in the meeting that there were lots of questions 
outstanding when the capwap-00 draft publication deadline approached, and 
rather than delay the release of that draft, we included the far-from-perfect 
text. I think we agreed in the wg meeting to form a small design team for the 
purpose of resolving these issues.

Further comments inline below...

-----Original Message-----
>From: "Nancy Winget (ncamwing)" <ncamwing [at] cisco.com>
>Sent: Mar 21, 2006 6:58 AM
>To: capwap <capwap [at] frascone.com>
>Subject: [Capwap] DTLS comments, questions and issues
>
>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?

Two comments: first, I agree that we should discuss whether this is required. I 
think we should break out that discussion into its own thread.

Perhaps one of the editors can add this to the issues tracker?

Secondly, DTLS is transport independent; the DTLS session is uniquely 
identified by the DTLS record layer. Combining this with the fact that DTLS is 
a datagram protocol, this net result is that a single DTLS security association 
may utilize multiple communication channels for transport (e.g. N separate 
ports) without penalty. I'm not arguing that we should do this - I think we 
need to address the underlying question of capwap data channel security before 
going there.

>* 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.

Yes, I agree that this is rough. There is fundamental tension here between the 
desire to provide DoS resistance (by remaining stateless until the last 
possible moment) and the desire to provide determinism in the state machine. I 
have some ideas about how to address this, but we need to decide something 
related to NAT traversal first. I will start a separate thread on that point so 
that we can move this forward.

>* 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.

Agree. This was inadverantly included, and is confusing.

>* 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.

Yes, the current intent is that DTLS-Complete implies an established session. 
We could change the state name (to DTLS-Established?) to make this more clear 
if that would help. There are currently two states as there are multiple exits 
possible from DTLS-Init (i.e. failure or success).  We could encode these 
multiple exits as separate transitions, but using separate states seems more 
clear.

This skirts a problem I noted when trying to edit the state machine: sometimes 
the emphasis is on the states, and sometimes the emphasis is on the transitions 
(moore vs mealy state machines?). This is quite confusing (to me, at least), 
and we should try to clean this up.

>  - 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.  

Agree that we need more complete specification of the state transitions...

>* 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.

Agree.

>* 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?

To be in DTLS-Reset implies that DTLS session tear-down has just completed, but 
there are still capwap session elements. That is, this state is entered when 
the DTLS security context has been destroyed. Once this occurs, DTLS notifies 
the capwap implementation, at which point capwap must destroy its session 
context (or re-initialize for a new session). 

>If so, then it is an effective Reset from the overall state machine
>standpoint....
>  - why does a new configuration warrant a DTLS-Reset?

I don't know. This change is propagated from lwapp-03 (where you can go from 
config to reset), and DTLS-reset is inserted ahead of the original reset 
transition. My guess is that the reset transition was intended for cases where 
the config change is so dramatic that a WTP reboot is required.

>  - why does an image update warrant a DTLS-Reset?

Again, so the wtp can reboot with the new image. There is a more subtle 
question lurking in the shadows here, though, and we can address this in the 
design team: should we support session resumption (a la TLS)?

>  - 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?

Because the DTLS session must be cleaned up first. I'd want to think about 
whether you'd want to collapse these into one state or not before saying more, 
but my gut feel is that separate states are warranted and add clarity to the 
spec. Still, let me think about this a bit more.

>* Why does a key refresh in the DTLS warrant a full state transition?
>What is implied by a DTLS-Rekey? 

This gets to some complexity which is not currently called out in the draft: 
DTLS does not provide support for session lifetimes - the controlling 
application must provide this functionality. This means we need to fully 
specify the rekeying interface between capwap and dtls.

As for whether it merits a full state transition, I think my original text said 
this is a meta-state, and that the rekeying happens "behind the scenes", below 
the awareness of capwap. However, I was wrong about that. Since capwap must 
provide the controls for this process, it must explicitly initiate the rekey, 
and it must decide to do if it fails. These factors lead me to believe that 
separate state is necessary.

Scott