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

Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing


Let me make a couple of observations here.  A lot of people have been
getting all excited about the "cookie crumb" attack, thinking that it's
something new, or something super serious.

First of all, it should be recognized that the designers of ISAKMP made
an engineering trade-off.  In Photuris, a cookie exchange was done at
the beginning before anything else was done.  This allowed the responder
to know that the initiator was coming from a valid IP address before
having to create *any* state.  However, this was done at the cost of an
extra round-trip.  In ISAKMP, some state does need to be created, but no
heavy-weight crypto operations need to be done until the second packet
from the initiator is received, at which point the initiator knows the
initiator is coming from a valid IP address.  The fact that this state
needs to be garbage collected is explicitly mentioned in RFC 2409:

   It should be noted that in the exchanges shown in section 4, the
   anticlogging mechanism should be used in conjuction with a garbage-
   state collection mechanism; an attacker can still flood a server
   using packets with bogus IP addresses and cause state to be created.
   Such aggressive memory management techniques SHOULD be employed by
   protocols using ISAKMP that do not go through an initial, anti-
   clogging only phase, as was done in [Karn].

Now, was this a bad decision?  It depends on how much you value
minimization of round-trips, and how bad you believe the resulting DoS
possibilities are as a result.  As regards to the latter question, it
should be noted that most of the TCP/IP infrastructure is subject to the
same problem; to wit, the SYN attack --- and there are defenses against
it.  It's interesting to note that defenses that worked well towards
prventing the SYN attack, such as random drop, also work just as well on
the so-called "cookie crumb" attack.

Furthermore, it's not true that the cookie prevents all DoS attacks.  It
simply prevents DoS attacks that come from spoofed IP address such that
it is hard to track down from whence they came.  In the TCP SYN attack,
part of the problem was that with the listen queue depth set at 5, it
was possible for a very low-bandwidth attack to completely paralyze a
host, and if an attack only required sending a packet or two per minute,
it was hard to identify the source, both to block it and to implement
out-of-band-corrective-measures (i.e., a smackdown).

But in the case of the "exploit" provided by Simpson, the IKE
implementation is flooded by cookies as fast as the receiver can send
them.  True, the IP addresses were masked so you couldn't trace it back
via the IP address.  But the packet flow is big enough that it should be
fairly easy to track it back simply by looking at the packet statistics
at various router interfaces.  This makes it very much unlike the TCP
Syn attack, and therefore much less of an issue.  True, Simpson's
program could modified to slow down the rate at which cookies were
issued, in an attempt to evade detection.  However, this also slows the
rate at which state needs to kept, and assuming that the recommendation
in RFC 2409 is followed to have a good garbage collection mechanism (and
a random drop technique when huge number of initial cookies are found in
the system should do the trick quite nicely --- see discussions
regarding the SYN attack about why this works), it's hard for me to see
why this is such a huge problem as some people make it out to be.

Fundamentally, it is extremely hard to defend against all denial of
service attacks.  If an attacker is willing to give away their location
(or at least their IP address), the cookie doesn't save you.  A large
part of the defense against DoS attacks is the knowledge that if it is
attempted that the problem can be easily traced back to the perpetrator.
This doesn't have to be by IP address, however.  If it involves a very
heavy packet flow, it can be just as easily traced back.  Hence, all
that is necessary is to harden an implementation to such a point that in
order to carry out such a clogging attack, the attacker is forced to use
a heavy enough flow that the flow can be easily traced back to the
source.

						- Ted
References: