Capwap Mailing List: Re: Issue 30: Inconsistent statetrackingonACpriortoDTLSEstablishment

[Pat Calhoun (pacalhou) (pcalhoun]

ok, sounds good. I have made the following changes to the previously
sent text. Note that I added text to the security considerations section
that handles the case you raised in another e-mail. I think we should
provide this additional guidance.

<new text>
2.3.1.  CAPWAP Protocol State Transitions
[...]
   Sulking to Sulking (a):  The Sulking state provides the silent
      period, minimizing the possibility for Denial of Service (DoS)
      attacks.

      WTP:  All packets received from the AC while in the sulking state
         are ignored.

      AC:  This is an invalid state transition for the AC.
[...]
   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.

12.3.  Discovery or DTLS Setup 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.  Discovery Request messages can
   easily be spoofed by malicious devices, so it is important that the
   AC maintain two separate sets of states for the WTP until the
   DTLSSessionEstablished notification is received, indicating that the
   WTP was authenticated.  Once a new DTLS session is successfully
   established, any state referring to the old session can be cleared.

   Similarly, entering the DTLS Setup phase SHOULD NOT assume that the
   WTP has reset, and therefore should not discard active state until
   the DTLS session has been successfully established.  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.

   Some implementations may wish to pass information about clients who
   have passed the discovery phase to the DTLS layer, authorizing only
   those clients to initiate a DTLS handshake.  Note that the impact of
   this on mitigating denial of service attacks against the DTLS layer
   is minimal, because DTLS already uses client-side cookies to minimize
   processor consumption attacks.  As a result, implementations SHOULD
   NOT maintain state between the discovery and DTLS handshake phases of
   the CAPWAP protocol initialization.
</new text> 

PatC

-----Original Message-----
From: Scott G. Kelly [mailto:s.kelly [at] ix.netcom.com] 
Sent: Wednesday, December 19, 2007 6:02 AM
To: Dorothy.Gellert [at] nokia.com; Pat Calhoun (pacalhou);
clancy [at] cs.umd.edu; capwap [at] frascone.com
Subject: RE: [Capwap] Issue 30: Inconsistent
statetrackingonACpriortoDTLSEstablishment

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
>>