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

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

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

---

From: Charles Clancy <[email-masked]>
Date: Fri, 01 Dec 2006 16:44:42 -0500

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