Subject: Re: [Capwap] Proposed resolution for Issue 226

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 1 Dec 2006 08:20:08 -0800

All,

Based on comments I have received, I would like to propose the following
changes. The primary issue has to do with the fact that the sulking
state was originally intended to stop a WTP from flooding an AC with
discovery requests, causing it to go quiet when the AC doesn't respond,
but this didn't expand to handle the new state machine. With the
introduction of DTLS, the state machine requires the state to go from
Idle to Join, via the establishment of the DTLS session. If that fails,
however, it would simply return to the Idle state, which once again
initiates the DTLS session. It is mandatory that we introduce a similar
quiet period that existed to protect against Discovery flooding in the
DTLS establishment process. The following text would allow the WTP or AC
to ignore all packets for a period of time when failed DTLS session
setup reaches a threshold.

2.3.  CAPWAP State Machine Definition
[...]
       /==============>=====================\
       "                                    "
       "  /==========<===============\      "
       "  "                          "t     v
       "  "   +--------------------------------------------------+
       "  "   |                       DTLS                       |
       "  "   +--------------------------------------------------+
       "  "   ^   "p              ^                      ^    DTLS
       "  ~~~~"~~~"~~~~~~~~~~~~~~~"~~~~~~~~~~~~~~~~~~~~~~"~~~~~~~~
       "  "   "   "               "                      "  CAPWAP
       "  "   "   "               "                      "
       "  "   "   "  /------------+----->-------------\  "
       "  "   "   "  |   /--------+---<---------+     |  "
       "  "  q"   v  |w  v        "r            |d    V  "
       "  "  +------------+  b+-----------+    +----------+  "
       ^  v  |    Idle    |-->| Discovery |--->|  Sulking |  "
       "  "  +------------+ a +-----------+ c  +----------+  "
       "  "                 |e            /--------------+-------\
       "  "                 |             |              "u      |
       "  "                 |    +----------+ o+-------------+   |
       "  "                 |    |   Run    |->|    Reset    |   |
       "  "                 |   n+----------+  +-------------+   |
       "  "                 |         ^         ^       ^        |
       "  "                 |         |   /-----/       |        |s
       "  "                 v        m|  k|             |l       v
       "  \==>+--------------+  +------------+ I      +------------+j
       "      |    Join      |->|  Configure |------->| Image Data |
       \======+--------------+ g+------------+        +------------+
             f

[...] <NOTE NEW STATE>
   Idle to Sulking (w):  This transition occurs on the DTLS session
      establishment process fails repeatedly to protect against DoS
      attacks.

      WTP:  The WTP enters this state when the FailedDTLSSessionCount
         counter reaches MaxFailedDTLSSessionRetry variable (see
         Section 4.7).  Upon entering this state, the WTP shall start
         the SilentInterval timer.  While in the Sulking state, all
         received CAPWAP and DTLS protocol messages received shall be
         ignored.

      AC:  The AC enters this state when the FailedDTLSSessionCount
         counter reaches MaxFailedDTLSSessionRetry variable (see
         Section 4.7).  Upon entering this state, the AC shall start the
         SilentInterval timer.  While in the Sulking state, all received
         CAPWAP and DTLS protocol messages received shall be ignored.
[...]
   Sulking to Idle (d):  This transition occurs on a WTP when it must
      restart the discovery phase.

      WTP:  The WTP enters this state when the SilentInterval timer (see
         Section 4.6) expires.

      AC:  The AC enters this state when the SilentInterval timer (see
         Section 4.6) expires.

2.3.3.  DTLS to CAPWAP Notifications
[...]
   o  n2: DTLSAuthenticateFail or DTLSAuthorizeFail is sent to the
      CAPWAP module to indicate peer authentication or authorization
      failures, respectively.  When this notification is received, the
      FailedDTLSSessionCount counter is monotonically increased.

   o  n3: DTLSEstablished is sent to the CAPWAP module to indicate that
      that a secure channel now exists.  When this notification is
      received, the FailedDTLSSessionCount counter is reset to zero.

[...]
4.6.7.  MaxFailedDTLSSessionRetry

   The maximum number of failed DTLS session establishment attempts
   before the CAPWAP device enters a silent period.

   Default: 3.

[...]
4.7.3.  FailedDTLSSessionCount

   The number of failed DTLS session establishment attempts.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

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

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

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 1 Dec 2006 12:12:45 -0800

My apologies, but I just noticed that I forgot to also include the
following change:

4.6.11.  SilentInterval

   For a WTP, this is the minimum time, in seconds, a WTP MUST wait
   before it MAY again send discovery requests or attempt to a establish
   DTLS session.  For an AC, this is the minimum time, in seconds,
   which the AC should ignore all CAPWAP and DTLS packets received from
   the WTP that is in the sulking state.

   Default: 30

Pat Calhoun

> -----Original Message-----
> From: Pat Calhoun (pacalhou) 
> Sent: Friday, December 01, 2006 8:20 AM
> To: capwap
> Subject: Re: [Capwap] Proposed resolution for Issue 226
> 
> All,
> 
> Based on comments I have received, I would like to propose 
> the following changes. The primary issue has to do with the 
> fact that the sulking state was originally intended to stop a 
> WTP from flooding an AC with discovery requests, causing it 
> to go quiet when the AC doesn't respond, but this didn't 
> expand to handle the new state machine. With the introduction 
> of DTLS, the state machine requires the state to go from Idle 
> to Join, via the establishment of the DTLS session. If that 
> fails, however, it would simply return to the Idle state, 
> which once again initiates the DTLS session. It is mandatory 
> that we introduce a similar quiet period that existed to 
> protect against Discovery flooding in the DTLS establishment 
> process. The following text would allow the WTP or AC to 
> ignore all packets for a period of time when failed DTLS 
> session setup reaches a threshold.
>

---

From: "Scott G. Kelly" <[email-masked]>
Date: Fri, 1 Dec 2006 13:16:37 -0800 (GMT-08:00)

Hi Pat,

I think you're ignoring probably the most significant comment you've received: I don't think what your proposing in terms of the dtls interactions is acceptable. I think this issue is sufficiently complex that we need to discuss it in person, so I'd recommend adding this to the agenda for the interim meeting. My current feeling is that there is no way this will fly from a security perspective.

Scott

-----Original Message-----
>From: "Pat Calhoun (pacalhou)" <[email-masked]>
>Sent: Dec 1, 2006 8:20 AM
>To: capwap <[email-masked]>

---

From: "Scott G. Kelly" <[email-masked]>
Date: Fri, 1 Dec 2006 18:21:46 -0500 (EST)

Hi Pat,

-----Original Message-----
>Sent: Dec 1, 2006 4:25 PM
>To: "Scott G. Kelly" <[email-masked]>, capwap <[email-masked]>
>Subject: RE: [Capwap] Proposed resolution for Issue 226
>
>ok, we can certainly discuss this face to face, but would appreciate
>understanding your comments/concerns so we can make progress. Is this
>the issue with the figure and the "conceptual" state transitions?

I think the biggest problem may stem from what I think must be a misperception. I'm getting the impression you think that DTLS is an add-on, and that CAPWAP need know nothing about its internals. I'm assuming this because you've said several times now that DTLS should be a black box as far as CAPWAP is concerned. This is fundamentally incorrect, in my view.

The CAPWAP protocol must provide certain security features. This is not an application where we want to have the user make a choice (like http), and where the app just needs to function, oblivious to the presence of security (or lack of it). Rather, security must be integral to the CAPWAP protocol design - it must be implicit, there must be a level of certainty that it is there and functioning correctly if the protocol is running.

We didn't pitch the integrated security of LWAPP because security is optional, or because we don't want to worry about security; we replaced it with DTLS because its the right thing to do from a security perspective. The security mechanism still needs to be as tightly coupled as it was with LWAPP - we've simply chosen a different mechanism. This implies that you must know something about the internals DTLS, or at least, that the implementation you choose provides certain critical hooks at certain critical points in its state machine. Those are what we've illustrated in the current diagram.

When I said the states in the DTLS portion of the diagram are conceptual, I did not mean "unreal", or "fantasy" states. I meant that this is a pragmatic rendition from the perspective of CAPWAP. Certainly, we could instead substitute a "real" dtls state machine, but I think we can accomplish what we need to without going there. On the other hand, if this will solve the problem for you, then let's discuss it.

The specification should (must, in my view) provide an implementation road map, at least when it comes to the security portions. Implementers are free to deviate from it if they see fit, but such decisions should be informed. Those who aren't security experts will be hard pressed to know exactly how to achieve the full benefit of the security features we're designing in if we don't show them a what's required for a nominally correct and secure implementation. That's what the diagram is intended to illustrate - no more, no less.

I'm not sure why you object to this. You are free to choose to implement something that is not nominally correct, so long as you don't impact interoperability, and still claim to comply with the spec. The diagram (and associated text) are only there to give you what you need to maximize security.

Scott

>> From: Scott G. Kelly [mailto:[email-masked]] 
>> Sent: Friday, December 01, 2006 1:17 PM
>> To: Pat Calhoun (pacalhou); capwap
>> I think you're ignoring probably the most significant comment 
>> you've received: I don't think what your proposing in terms 
>> of the dtls interactions is acceptable. I think this issue is 
>> sufficiently complex that we need to discuss it in person, so 
>> I'd recommend adding this to the agenda for the interim 
>> meeting. My current feeling is that there is no way this will 
>> fly from a security perspective.
>> 
>> Scott
>> 
>> 
>> >Based on comments I have received, I would like to propose the 
>> >following changes. The primary issue has to do with the fact 
>> that the 
>> >sulking state was originally intended to stop a WTP from 
>> flooding an AC 
>> >with discovery requests, causing it to go quiet when the AC doesn't 
>> >respond, but this didn't expand to handle the new state 
>> machine. With 
>> >the introduction of DTLS, the state machine requires the state to go 
>> >from Idle to Join, via the establishment of the DTLS 
>> session. If that 
>> >fails, however, it would simply return to the Idle state, which once 
>> >again initiates the DTLS session. It is mandatory that we 
>> introduce a 
>> >similar quiet period that existed to protect against 
>> Discovery flooding 
>> >in the DTLS establishment process. The following text would 
>> allow the 
>> >WTP or AC to ignore all packets for a period of time when 
>> failed DTLS

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 1 Dec 2006 15:50:39 -0800

I 

 -----Original Message-----
From: 	Scott G. Kelly [mailto:[email-masked]]
Sent:	Friday, December 01, 2006 03:21 PM Pacific Standard Time
To:	Pat Calhoun (pacalhou); capwap
Subject:	RE: [Capwap] Proposed resolution for Issue 226

Hi Pat,

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

Scott

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 4 Dec 2006 07:48:58 -0800

ah, I see.

Well, I think why I am having a hard time with this specific approach is
that there is no guarantee that a notification sent by DTLS will occur
while it is in a "conceptual" state. If I use OpenSSL, and I receive a
notification, how am I supposed to know whether it was in the Run or
Disconnected state? All I get is a notification, so relying on having to
know the internals of DTLS makes it nearly impossible.

Describing the DTLS state machine to "limit" the number of alerts is not
particularly useful, because the CAPWAP stack will have to deal with the
alerts as they come in. There is nothing that a diagram can do to help
the implementer deal with the notifications.

I think there is a way to resolve this issue, though. I believe what is
needed is some language that clearly describes that the DTLS
notifications can occur at any time, and what happens when they are
received while in different CAPWAP states. This would be in the DTLS
notifications section, and would include a significant amount of new
text on each notification, and how they are to be treated when they are
"expected", and not. The important information here is not what DTLS
state we are in, but rather what CAPWAP state we are in.

Correct?

Pat Calhoun

> From: Charles Clancy [mailto:[email-masked]] 
> Sent: Sunday, December 03, 2006 10:56 AM
> To: Pat Calhoun (pacalhou)
> Cc: Scott G. Kelly; capwap
> Pat,
> At least for my objections, it doesn't have anything to do 
> with CAPWAP knowing the state of DTLS, or being able to 
> enforce it.  It's more about how you draw the state machine 
> and describe the transitions.
> 
> In your black-box version of DTLS, you have a variety of 
> lines coming out of a single "state" indicating all the 
> different DTLS alerts.  The problem with that is it indicates 
> DTLS could send up any alert at any time.  Thus, in the 
> description for every single CAPWAP state, you need to 
> specify what happens if any of the alerts are received.
> 
> Of course, in a real system, DTLS can only send one or two 
> alerts at any particular time, based on its own internal 
> state.  This is the current assumption used in the current 
> state machine, and for the affected CAPWAP states we only 
> describe how these one or two alerts affect the CAPWAP state. 
>  We can ignore all the other alerts, because there's no way 
> we could possibly receive them given the current DTLS "conceptual" 
> state.
> 
> We need to capture just enough of the DTLS state machine to 
> limit the number of alerts that can be received by CAPWAP at 
> any particular time. 
>   It will make proper specification of the state transitions 
> signficantly easier, and less prone to error.  We can achieve 
> the same formal security properties if we treat DTLS as a 
> simple black box, but it would require a lot more text to do properly.
> 
> --
> t. charles clancy, ph.d.  |  [email-masked]  |  www.cs.umd.edu/~clancy
> 
> 
> Pat Calhoun (pacalhou) wrote:
> > I wish to preface my e-mail with the fact that I do want to 
> do what's 
> > right from a security perspective, and am sensitive to your (and 
> > scott's) comments.
> > 
> >> Keeping the DTLS conceptual states enforces an order to which 
> >> commands and alerts can occur.  There should be a one-to-one 
> >> relationship between CAPWAP states and DTLS conceptual states for 
> >> which there is CAPWAP-DTLS interaction.  There isn't right 
> now, and I 
> >> think this should be fixed.
> > 
> > I really am not trying to be difficult, but I have a hard time 
> > understanding what you are saying. You claim there should be a 
> > one-to-one relationship between CAPWAP states and DTLS "conceptual" 
> > states, but the problem is that these DTLS states *are* conceptual. 
> > There is NO way to guarantee that the DTLS stack is 
> operating based on 
> > what the CAPWAP protocol would say. So what happens if a 
> DTLS stack is 
> > non-conformant with our definitions of the conceptual 
> states. is this 
> > a CAPWAP problem or a DTLS problem?
> > 
> >> Without enforcing such an order, and having such a bijective 
> >> relationship, policy for handling incoming DTLS alerts becomes 
> >> difficult from a security perspective.  For example, by specifying 
> >> the conceptual DTLS states, we're definitely saying we 
> should never 
> >> receive a DTLSRehandshake message when the CAPWAP state 
> machine is in 
> >> the Join state.  Thus if we receive one we can either ignore it or 
> >> move CAPWAP into some error state.  Without this, we would need to 
> >> enumerate every possible DTLS alert and specify for every CAPWAP 
> >> state what the CAPWAP state transition should be upon reception of 
> >> that alert in order to preserve the security properties.
> > 
> > But you make the assumption that the CAPWAP protocol actually has 
> > visibility into these packets. These DTLS packets are encrypted and 
> > are processed outside the CAPWAP protocol. Some of them will be 
> > processed without CAPWAP's knowledge, unless there is an explicit 
> > notification for each packet it receives.
> > 
> > So how is the CAPWAP protocol supposed to enforce/limit 
> what messages 
> > will/will not be processed by DTLS?
> > 
> > I guess the question I have is whether the DTLS module in 
> the CAPWAP 
> > spec is intended to be a library or a protocol. You seem to 
> imply the 
> > former, while I am under the impression it is the latter.
> > 
> > 
> > Pat Calhoun
> >> From: Charles Clancy [mailto:[email-masked]] 
> >> Sent: Friday, December 01, 2006 1:45 PM
> >> To: Pat Calhoun (pacalhou)
> >> Cc: Scott G. Kelly; capwap
> >> Pat,
> >> (These are my objections to completely eliminating the DTLS 
> >> state machine... Scott may have other objections in addition 
> >> to mine...)
> >>
> >> Keeping the DTLS conceptual states enforces an order to which 
> >> commands and alerts can occur.  There should be a one-to-one 
> >> relationship between CAPWAP states and DTLS conceptual states 
> >> for which there is CAPWAP-DTLS interaction.  There isn't 
> >> right now, and I think this should be fixed.
> >>
> >> Without enforcing such an order, and having such a bijective 
> >> relationship, policy for handling incoming DTLS alerts 
> >> becomes difficult from a security perspective.  For example, 
> >> by specifying the conceptual DTLS states, we're definitely 
> >> saying we should never receive a DTLSRehandshake message when 
> >> the CAPWAP state machine is in the Join state.  Thus if we 
> >> receive one we can either ignore it or move CAPWAP into some 
> >> error state.  Without this, we would need to enumerate every 
> >> possible DTLS alert and specify for every CAPWAP state what 
> >> the CAPWAP state transition should be upon reception of that 
> >> alert in order to preserve the security properties.
> >>
> >> --
> >> t. charles clancy, ph.d.  |  [email-masked]  |  www.cs.umd.edu/~clancy
> >>
> >>
> >> Pat Calhoun (pacalhou) wrote:
> >> which once 
> +--------------------------------------------------+
> >>>>>       "  "   |                       DTLS               
>         |
> >>>>>       "  "   
> +--------------------------------------------------+
> >>>>>       "  "   ^   "p              ^                      
> ^    DTLS
> >>>>>       "  
> ~~~~"~~~"~~~~~~~~~~~~~~~"~~~~~~~~~~~~~~~~~~~~~~"~~~~~~~~
> >>>>>       "  "   "   "               "                      
> "  CAPWAP
> >>>>>       "  "   "   "               "                      "
> >>>>>       "  "                 |             |              
> "u      |
> >>>>>       "  "                 |         ^         ^       
> ^        |
> >>>>>       "  "                 |         |   /-----/       
> |        |s
> >>>>>       "  "                 v        m|  k|             
> |l       v