Subject: Re: [Capwap] Issue 30: Inconsistent statetrackingonAC priortoDTLSEstablishment

From: "Scott G. Kelly" <[email-masked]>
Date: Wed, 19 Dec 2007 06:02:19 -0800 (GMT-08:00)

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: [email-masked]
>Sent: Dec 18, 2007 5:11 PM
>To: [email-masked], [email-masked], [email-masked], [email-masked]
>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:[email-masked]] 
>> 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:[email-masked]]
>> 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)" <[email-masked]>
>> >Sent: Dec 17, 2007 3:45 PM
>> >To: "Scott G. Kelly" <[email-masked]>, Charles Clancy
>> <[email-masked]>, capwap <[email-masked]>
>> >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
>> 

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 19 Dec 2007 11:22:27 -0800

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:[email-masked]] 
Sent: Wednesday, December 19, 2007 6:02 AM
To: [email-masked]; Pat Calhoun (pacalhou);
[email-masked]; [email-masked]
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:

  Section 4.8), implementations MAY choose to rate-limit new DTLS
handshakes
  for some period of time. It is RECOMMENDED that implementations
choosing

--Scott

-----Original Message-----

>> Subject: Re: [Capwap] Issue 30: Inconsistent statetrackingonAC 
>> priortoDTLSEstablishment
>> 
>> Could you provide some, and I can remove the (d) transition for the 
>> AC.
>> 
>> PatC
>> 
>> Subject: Re: [Capwap] Issue 30: Inconsistent state trackingonAC 
>> priortoDTLSEstablishment
>> 
>> Hi Pat,
>> 
>> Yes, the current text does preclude entering sulking state based on 
>> discovery messages. That's good. However, the proposed text says
>> 
>> 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
>> 
>> 
>>

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 20 Dec 2007 09:03:56 -0800

All,

In an attempt to address Scott's issues, I have made an additional
change to remove the sulking state on the AC. This has caused the
recommendations to perform rate limiting to only be present in the
security considerations text (sent yesterday).

<revised text>
2.3.  CAPWAP State Machine Definition
[...]
                            /-------------------------------------\
                            |          /-------------------------\|
                            |         w|                         ||
                            |    x+----------+ y +------------+  ||
                            |     |   Run    |-->|   Reset    |-\||
                            |     +----------+   +------------+ |||
                           u|  V      ^           ^     ^      z|||
                +------------+--------/           |     |       |||
                | Data Check |             /-------/    |       |||
                +------------+<-------\   |             |       |||
                                      |   |             |       |||
                       /------------------+--------\    |       |||
                      m|             t|  o|    q   v   r|       |||
               +--------+     +-----------+     +--------------+|||
               |  Join  |---->| Configure |     |  Image Data  ||||
               +--------+  n  +-----------+     +--------------+|||
                ^   |l                 p|                    s| |||
                |   |                   \-------------------\ | |||
                |   \--------------------------------------\| | |||
                \------------------------\                 || | |||
         /--------------<----------------+---------------\ || | |||
         | /------------<----------------+-------------\ | || | |||
         | |                       i      |k           8| | vv v vvv
         | |   +----------------+<--+--------------+   +-----------+
     /---|-|---|   DTLS Setup   |   | DTLS Connect |-->|  DTLS TD  |
     | /-|-|---+----------------+e  +--------------+ 7 +-----------+
     | | | | d  |6  ^      ^  |f         ^       j|      ^  |~
     v v v v    |   |      |  |          |        |      |  |
     | | | |    |   |      |  \-------\  |   /----+------/  |
     | | | |    |   |      |          |  |   |    \---\     |
     | | | |    v  c|  1   |5    2    v  |g  |h       v     v
     | | | \->+------+-->+------+   +-----------+    +--------+
     | | |    | Idle |   | Disc |   | Authorize |    |  Dead  |
     | | |    +------+<--+------+   +-----------+    +--------+
     | | |        ^    0      |3                         ^
     | | |        |           |                          |b
     | | |9       |4          |                          |
     | | \->+---------+<------/                          |
     | \--->| Sulking |                                  |
     |      +---------+a                                 |
     \---------------------------------------------------/

                 Figure 3: CAPWAP Integrated State Machine

[...]
   Listener Thread -   The AC's Listener thread handles the shared
      services, which includes receiving and responding to Discovery
      Requests.  The Listener thread handles the common tasks, up to the
      DTLS Setup state.  The state machine transitions in the above
      figure are represented by numerals.  It is necessary for the AC to
      protect itself against various attacks that exist with non-
      authenticated frames.  See Section 12 for more information.

2.3.1.  CAPWAP Protocol State Transitions
[...]
   DTLS Setup to Dead (b):  This transition occurs on the AC when the
      DTLS connection establishment process fails.

      WTP:  This is an invalid state transition for the WTP.

      AC:  The AC initiates this state transition when it receives a
         DTLSEstablishFail notification from DTLS (see Section 2.3.2.2).
         This error notification aborts the secure DTLS session
         establishment.  When this notification is received, the
         FailedDTLSSessionCount counter is incremented.  The AC must
         clean up all resources associated with the control plane DTLS
         session The data plane DTLS session is also shutdown, and all
         resources freed, if a DTLS session was established for the data
         plane.  Any timers set for the current instance of the state
         machine are also cleared.  The AC's Service thread is
         terminated. 
</revised text>

PatC
-----Original Message-----
From: Pat Calhoun (pacalhou) 
Sent: Wednesday, December 19, 2007 11:22 AM
To: Scott G. Kelly; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [Capwap] Issue 30:
InconsistentstatetrackingonACpriortoDTLSEstablishment

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

PatC

-----Original Message-----
From: Scott G. Kelly [mailto:[email-masked]]
Sent: Wednesday, December 19, 2007 6:02 AM
To: [email-masked]; Pat Calhoun (pacalhou);

Hi Dorothy,

--Scott