Capwap Mailing List: Re: Issue 30: Inconsistent state tracking onAC priortoDTLSEstablishment

[Scott G. Kelly (s.kelly]

Hi Pat,

-----Original Message-----
>From: "Pat Calhoun (pacalhou)" <pcalhoun [at] cisco.com>
>Sent: Dec 17, 2007 3:45 PM
>To: "Scott G. Kelly" <scott [at] hyperthought.com>, Charles Clancy <clancy 
>[at] cs.umd.edu>, capwap <capwap [at] frascone.com>
>Subject: RE: [Capwap] Issue 30: Inconsistent state tracking onAC       
>priortoDTLSEstablishment
>
>The current spec clearly states:
>
>12.3.  Discovery Attacks
>
>   Since the Discovery Request messages are sent in the clear, it is
>   important that AC implementations NOT assume that receiving such a
>   request from a WTP implies that it has rebooted, and consequently
>   tear down any active DTLS sessions.
>
>We can expand this text to include the initiation of DTLS sessions.
>

Yes, the current text does preclude entering sulking state based on discovery 
messages. That's good. However, the proposed text says

   DTLS Setup to Sulking (d):  This transition occurs when repeated
      attempts to setup the DTLS connection have failed.
                :
                :
      AC:  The AC enters this state with the specific WTP when the
         FailedDTLSSessionCount or the FailedDTLSAuthFailCount counter
         reaches MaxFailedDTLSSessionRetry variable (see Section 4.8).
         Upon entering this state, the AC's Service thread MUST start
         the SilentInterval timer, and ignore all CAPWAP and DTLS
         protocol messages received from the WTP.  The AC immediately
         transitions the state to Idle.

This implies that if dtls session setup is spoofed, any active (valid!) 
sessions will be effectively disconnected, and (valid!) WTP recovery attempts 
will be ignored. If the attacker re-does this attack each time the 
SilentInterval (default: 30 seconds) expires, valid WTPs can be prevented from 
reconnecting indefinitely. This is the unauthenticated DoS I was referring to.

--Scott