Subject: [Capwap] DTLS comments, questions and issues

From: "Nancy Winget (ncamwing)" <[email-masked]>
Date: Tue, 21 Mar 2006 06:58:32 -0800

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

---

From: Michael Montemurro <[email-masked]>
Date: Tue, 21 Mar 2006 10:18:00 -0500

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:[email-masked]] 
> 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?
> 
>   - 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?
> * 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....
>   - 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?
>

---

From: "Nancy Winget (ncamwing)" <[email-masked]>
Date: Tue, 21 Mar 2006 07:19:25 -0800

Hi Mike,

Yes, that makes sense.  Thanks,

	Nancy. 

-----Original Message-----
From: Michael Montemurro [mailto:[email-masked]] 
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.

Cheers,

	Mike 

> have a few more to add (though I stopped once I realized that most of 
> my original comments stand as well):
> 
> 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?
> 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.
> 
> DTLS-Init to Discovery seem too similar.  What is the difference 
> between an unsuccessful DTLS session establishment and a failed DTLS 
> handshake?
> 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

>   - it seems that perhaps for both of the above, the WTP should go 
> back to Idle or DTLS-Init again.

---

From: "Scott G. Kelly" <[email-masked]>
Date: Tue, 21 Mar 2006 07:58:14 -0800 (GMT-08:00)

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)" <[email-masked]>
>Sent: Mar 21, 2006 6:58 AM
>To: capwap <[email-masked]>

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.

>enter this state as it is initiating a potential connection with the

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.

>A similar conflict arises in the AC's descriptions.

Agree. This was inadverantly included, and is confusing.

>capture of the DTLS state machine is warranted and these 2 states do not

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 DTLS session is live and is authorized to begin protected traffic.  

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

>suggestion is that when these fail, they should go back to the Idle

Agree.

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

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

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

>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

---

From: "Nancy Winget (ncamwing)" <[email-masked]>
Date: Tue, 21 Mar 2006 08:45:46 -0800

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:[email-masked]] 
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.

-----Original Message-----
>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 

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.

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.

>enter this state as it is initiating a potential connection with the 

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.

handshake?

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

traffic.

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

Agree.

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

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

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

>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

---

From: "Abhijit Choudhury" <[email-masked]>
Date: Wed, 22 Mar 2006 09:33:57 -0800

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:[email-masked]] 
Sent: Tuesday, March 21, 2006 8:46 AM
To: Scott G. Kelly; capwap
Subject: RE: [Capwap] DTLS comments, questions and issues

Hi Scott,

-----Original Message-----

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.

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.

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.

handshake?

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.  

traffic.

Agree.

Scott