[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Denial of Service Testing Results


I've used a program derived from Simpson's, as well as another program
of my own to do some testing for the practicality of IPSec DoS
attacks.  I have a few IPSec devices from different vendors with which
I can do this testing.  While there are certainly theoretical DoS
attacks against IKE, I don't think these attacks are very real, and I
don't think the IPSec specifications need to be changed.

I was able to use (a variation of) Simpson's code to flood some
devices, sometimes using up to 100% of the CPU, but I don't think it
had anything to do with IPSec.  Later testing of sending just a few
hundred IKE message 1's showed that the first few (around 50-100) got
responses, while the rest were just ignored.  It takes resources to
ignore many messages, perhaps maxing out the network card, or filling
the input buffer.  I think it could have been any type of packet
coming that fast.

While the above attack was going on, I checked the memory usage on the
Windows machine, and it barely moved.  I don't think the "cookie
crumbs" amounted to a hill of beans.  The suggested garbage collection
was probably working, and connections beyond what the device could
handle were just dropped.

One of the gateway devices required me to type in the address of the
other gateway I could have multiple gateways for the other side, but I
had to type each one in.  This prevented me from using the spoofing
capability in Simpson's code, and the gateway was smart enough to
attempt to finish (timeout, in this case) one negotiation with a
location before responding to another IKE request from the same
address.

Another gateway allowed wildcard characters for the other gateway.
However, this one ran in Main Mode.  I could get similar results using
the flooding reported above.  To test if the Diffie-Hellman
calculation slowed things down, I created another program to capture
the returned IKE message 2, grab the cookie out of it, and then send a
bogus message 3 at the target.  The target just didn't respond to IKE
message 1's fast enough, only creating occasional message 2's, so the
message 3's appeared relatively infrequently (compared to the
frequency of the message 1's), and the target was able to keep up
generating message 4's.

One problem with collecting message 2's to force the Diffie-Hellman
calculation in Main Mode is that you must be on the return path of the
spoofed IP address.  Gaining this much access to a target can be very
difficult.

I also did some testing by sending a few hundred IKE packets at
something that could do either Main Mode or Aggressive Mode.  In each
case, it dropped everything other than approximately the first 60
negotiations (MM) or 35 negotiations (AM).  And because it only
started up 35 Aggressive Mode negotiations, it was able to time them
out quicker, and recover FASTER than against the Main Mode attack.

I've also heard the some IPSec devices can handle 500, or maybe 1,000
simultaneous connections.  I haven't figured out how these work.  Are
those 500 completed IKE exchanges, or 500 initiated ones?  If only
initiated, then one could use up these resources (as opposed to CPU or
memory) using the flooding from above, and then only send an
occasional new connection to take the place of timed out connections.

To sum up - I don't see much of a DoS problem between gateways (one
very common use of IPSec).  I don't see much of a DoS problem in Main
Mode.  And in the most common cases remaining (Aggressive Mode, and
Remote Access), I think garbage collecting, and timing out
negotiations can be effectively used.  You can't stop all DoS attacks,
but I don't see a need to rewrite the IPSec documents to handle this.

There are issues I haven't been able to test, and maybe someone can
provide some answers.  Devices that are specifically designed to
accept Remote Access connections can be connected to from any IP
address.  I didn't test any of these - only gateway devices that
allow wildcard characters.  How would they stand up to this testing?
What about hardware IPSec boxes that may have limited memory?

Has anyone gotten any of these attacks to work in practice?  Can
anyone suggest a thorough DoS test plan?  What other defenses do
implementors use against DoS in IPSec?


Dave Opitz
NSA
opitz@thematrix.ncsc.mil