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

Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing



Dave Perks wrote:
 
> Paul Koning wrote:
> >
> > I have a concern about this notion of using puzzles as a way of
> > addressing the DoS problem.

Imposing extra overheads on the initiator as a way of reducing the risk
of a DoS attack makes the attack more costly, but not less effective.

As Paul poimts out, it also makes legitimate connections more costly.
I don't think that problem is as serious as he suggests, but it is
clearly a problem.
 
> For that matter, the recent much-publicized distributed DoS attacks on
> e-commerce servers point out  that a similar attack on an IPsec server
> would have no problem overcoming a puzzle-based defence. The multitude
> of "zombie" attackers collectively has much more CPU power than any
> attacked system.

So the questions are: How to limit the responder's commitment of resources, both memory
and CPU, on receipt of bogus connection requests,
bogus ESP or AH packets, bogus anything the protocol specifies, and how
to recover resources on discovering bogosity.

I'm not certain there's much we can do to defend against bogus IPSEC
packets. If the attacker can see some of our legitmate packets or
knows who our partners are, then they can produce forged packets that
we cannot reject until we've done the authentication, so an attacker
can always force us to do authentication. If they can throw packets at
us faster than we can test them, then they can always bog us down at
least temporarily.

I think this is a strong argument for rejecting Schneier and Ferguson's
advice on one point. They argue that we should be authenticating
plaintext instead of ciphertext, but if we did that, then we'd have to
decrypt packets before we could authenticate and the overheads a DoS
attacker could require of us would go way up.

If they're right and we should be authenticating plaintext, then we
need to do that as well as, not instead of, authenticating the
encrypted packets.

It is also, I think, an argument for leaving some "headroom" in your
capacity planning for gateway servers. If you're specifying a gateway,
it becomes a requirement that your IPSEC implementation be able to
authenticate packets faster than your connection can deliver them. If
you're building an implementation, you should test that it survives
this attack and can recover to normal operation. 

As for bogus connection requests, making them expensive for the
initiator doesn't solve the problem. We need to limit resource
commitment in the responder, at least until we see the second packet
from the initiator. We need to time out and recover resources if the
second packet does not arrive.

Finally, we need some form of 'cookie' that makes constructing a bogus
second packet extremely difficult for an attacker who has not received
our reply to the first. The attacker can likely get UDP 500 packets to
us, and can construct packets of the appropriate types in sequence, but
if we make this hard, he has a problem.

As I read Simpson's lament, the main technical issue he raises is that
IKE does not limit the responder's resource commitment appropriately.
Can someone please give me a pointer to a refutation of that notion?

Failing that, is there a solution to this problem?


References: