| Re: Issue 30: InconsistentstatetrackingonACpriortoDTLSEstablishment | <– Date –> <– Thread –> |
From: Pat Calhoun (pacalhou) (pcalhoun cisco.com)
|
|
| Date: Thu, 20 Dec 2007 09:04:05 -0800 (PST) | |
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; Dorothy.Gellert [at] nokia.com; clancy [at] cs.umd.edu;
capwap [at] frascone.com
Subject: Re: [Capwap] Issue 30:
InconsistentstatetrackingonACpriortoDTLSEstablishment
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
>>
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap
Archives: http://lists.frascone.com/pipermail/capwap
-
Re: Issue 30: Inconsistent statetrackingonAC priortoDTLSEstablishment Scott G. Kelly, December 19 2007
-
Re: Issue 30: Inconsistent statetrackingonACpriortoDTLSEstablishment Pat Calhoun (pacalhou), December 19 2007
- Re: Issue 30: InconsistentstatetrackingonACpriortoDTLSEstablishment Pat Calhoun (pacalhou), December 20 2007
-
Re: Issue 30: Inconsistent statetrackingonACpriortoDTLSEstablishment Pat Calhoun (pacalhou), December 19 2007
Results generated by Tiger Technologies using MHonArc.