Capwap Mailing List: Re: Issue 30: Inconsistent statetrackingonAC priortoDTLSEstablishment

[Scott G. Kelly (s.kelly]

Hi Dorothy,

Dealing with clogging attacks is fairly well understood, and the approach you 
take depends on various factors. As Pat said, there is no perfect solution. But 
there are solutions which minimize the effect on valid peers. 

Sulking, as currently defined, causes the AC to ignore *all* messages from a 
given IP, but what we actually want to do is to alleviate the DoS attack while 
still allowing normal operations. We can accomplish this by limiting the number 
of new DTLS handshakes the AC participates in. Ideally, we'd like valid WTPs to 
still be able to connect and/or use already-established sessions, and to suffer 
only a limited reduction in service as a result of the attack (or malfunction).

I provided suggested language for this as part of one of the transitions to 
"sulking" in a private email while we were at IETF a few weeks back. Here it is 
again, modified according to the edits Pat submitted to the list:


DTLS Setup to Sulking (d):  This transition occurs when repeated
   attempts to setup the DTLS connection have failed.

AC: This transition is a no-op for the AC. While the HelloVerifyRequest
  provides some protection against denial of service (DoS) attacks on 
  the AC, an adversary capable of receiving packets at a valid address 
  (or a malfunctioning or misconfigured WTP) may repeatedly attempt DTLS 
  handshakes with the AC, potentially creating a resource shortage. If 
  either the FailedDTLSSessionCount or the FailedDTLSAuthFailCount 
  counter reaches the value of MaxFailedDTLSSessionRetry variable (see 
  Section 4.8), implementations MAY choose to rate-limit new DTLS handshakes
  for some period of time. It is RECOMMENDED that implementations choosing
  to implement rate limiting use a random discard technique, rather than
  mimicking the WTP's sulking behavior. This will ensure that messages 
  from valid WTPs will have some probability of eliciting a response,  
  even in the face of a significant DoS attack.

-------------------------

--Scott


-----Original Message-----
>From: Dorothy.Gellert [at] nokia.com
>Sent: Dec 18, 2007 5:11 PM
>To: pcalhoun [at] cisco.com, scott [at] hyperthought.com, clancy [at] 
>cs.umd.edu, capwap [at] frascone.com
>Subject: RE: [Capwap] Issue 30: Inconsistent statetrackingonAC 
>priortoDTLSEstablishment
>
>Hi All,
>
>I wanted to thank Pat and Scott for collaborating on Issue 30 so far.
>As for this last nagging point, somehow I imagine protecting an AC from
>flooding attacks sounds easier said than done.   Do the security experts
>out there on the list have any proposals on this remaining glitch so we
>can close Issue 30?
>
>I know this is a busy time with the holidays, so any help is very
>appreciated!
>
>Dorothy
>
>
>> -----Original Message-----
>> From: ext Pat Calhoun (pacalhou) [mailto:pcalhoun [at] cisco.com] 
>> Sent: Monday, December 17, 2007 3:02 PM
>> To: Scott G. Kelly; Charles Clancy; capwap
>> Subject: Re: [Capwap] Issue 30: Inconsistent 
>> statetrackingonAC priortoDTLSEstablishment
>> 
>> I'm happy to change this by simply adding text that you feel 
>> adequately protects the AC from a flooding attack.
>> 
>> Could you provide some, and I can remove the (d) transition 
>> for the AC.
>> 
>> PatC 
>> 
>> -----Original Message-----
>> From: Scott G. Kelly [mailto:s.kelly [at] ix.netcom.com]
>> Sent: Monday, December 17, 2007 1:19 PM
>> To: Pat Calhoun (pacalhou); Charles Clancy; capwap
>> Subject: Re: [Capwap] Issue 30: Inconsistent state 
>> trackingonAC priortoDTLSEstablishment
>> 
>> 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
>> 
>> 
>> 
>> _________________________________________________________________
>> 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
>>