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

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

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
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: Charles Clancy [mailto:[email-masked]] 
> Sent: Friday, December 01, 2006 1:45 PM
> To: Pat Calhoun (pacalhou)
> Cc: Scott G. Kelly; capwap
> Subject: Re: [Capwap] Proposed resolution for Issue 226
> 
> 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:
> > 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?
> > 
> > Pat Calhoun
> > CTO, Wireless Networking Business Unit
> > Cisco Systems
> > 
> >  
> > 
> >> -----Original Message-----
> >> From: Scott G. Kelly [mailto:[email-masked]] 
> >> Sent: Friday, December 01, 2006 1:17 PM
> >> To: Pat Calhoun (pacalhou); capwap
> >> Subject: Re: [Capwap] Proposed resolution for Issue 226
> >>
> >> 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]>
> >>> 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.
> >>>
> >>> 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
> > _________________________________________________________________
> > To unsubscribe or modify your subscription options, please visit:
> > http://lists.frascone.com/mailman/listinfo/capwap
> > 
> > Archives: http://lists.frascone.com/pipermail/capwap
> 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: Charles Clancy <[email-masked]>
Date: Sun, 03 Dec 2006 13:55:56 -0500

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.