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

[Abhijit Choudhury (Abhijit]

Hi,
As I mentioned at the meeting, I too was quite surprised at
the inclusion of DTLS protection on the data path without
any prior discussion and without enough details.

1. It's not clear to me that DTLS protection of the
data tunnel is necessary.
Vendors who decrypt packets at the WTP clearly think the
path from WTP to the AC is secure.  Others carry 802.11i
encryption all the way to the AC and would not require DTLS.
So, why complicate the spec with this additional mode ?

2. The next issue is whether the same key should be used to
protect the control and data tunnels. If not, there has to
be a way to initiate multiple DTLS sessions.

3. Also, is there a current restriction that there can be 
ONLY one data tunnel ? The way the current spec is written
it seems that multiple data tunnels is possible.
Although a single UDP port may be used at the 
AC, multiple ports could be used at the WTP to define
multiple data tunnels identified by 
   (WTP-IP, WTP_port, AC-IP, AC-PORT)

For example, some vendor may want multiple data 
tunnels to distinguish traffic frm different VLANs, or BSSIDs or
traffic for different service providers at a hot spot.
If this is possible, it seems that mutiple DTLS sessions
will be quite likely.

Thanks,
   Abhijit




-----Original Message-----
From: Nancy Winget (ncamwing) [mailto:ncamwing [at] cisco.com] 
Sent: Tuesday, March 21, 2006 8:46 AM
To: Scott G. Kelly; capwap
Subject: RE: [Capwap] DTLS comments, questions and issues


Hi Scott,

I believe Mike has separated the general DTLS comments/issues I posted
as issue 86 while the DTLS for data transport is issue 87.

Nonetheless, further comments to yours below: 

-----Original Message-----
From: Scott G. Kelly [mailto:s.kelly [at] ix.netcom.com] 
Sent: Tuesday, March 21, 2006 7:58 AM
To: Nancy Winget (ncamwing); capwap
Subject: Re: [Capwap] DTLS comments, questions and issues

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. [NCW] Agreed....it's not clear to me that this was openly
discussed before and was surprised by its inclusion (albeit with lack of
details) in this draft.

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. [NCW] While I'm sure
that a single DTLS security association can provide the means of
securing two different communication channels, I believe updates to the
DTLS and specifically to the applicability for CAPWAP must be explicitly
defined.  [D]TLS only describes the generation of keying material for
securing only a single channel, so consideration for the extra material
has to be explicitly defined.  Also, the security considerations and
threat models must also be provided.

>* 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. [NCW] I
will look forward to exploring this with you.

>* 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. [NCW] I
agree. The benefit of having included DTLS is having separated the
mechanism for securing the communication channel as well as providing
better agility for the crypto; however, such benefits introduce more
complexity than was originally specified.  Having stated that, we may
have to resort to such state machines as you suggest....it may also be
that we may have to resort splitting the state machines one for the WTP
and one for the AC.  

>  - 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). 
[NCW] Okay, it seems that we agree in principle, though I think from the
state machine, there seems to be an implication that a DTLS-Reset does
not force a "capwap" reset.  I believe that whether the DTLS-Reset fails
or succeeds, it must be in conjuction with a "capwap" reset.

>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.
[NCW] Ah, got it.  My question went more to the original comment of
converging DTLS-Reset and Reset into the same state.

>  - 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)?
[NCW] Same comment as above.  Though, I think we do need to be somewhat
careful between a full teardown of DTLS vs. a session resumption.  I'd
prefer that the resumption be construed as a "rekey" (which I don't
believe needs to be called out as a separate state) and the DTLS-reset
should be a full teardown of the DTLS session.

>  - 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.
[NCW] Fair enough.  I do believe that they can be merged as the reset
imho would imply initiating the DTLS teardown as well as the "capwap"
particular cleanup.

>* 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.
[NCW] Rekeying was part of the original draft, albeit the lifetimes were
not explicitly called out.  Though, this may be construed as policy
driven?

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.
[NCW] Hmmm...I will have to think about promoting the rekey into a full
state as well....your comment of rekey failures forcing a teardown
(Reset?) is fair.

Scott
 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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