[Swan-dev] [IPsec] A strategy against DoS/DDoS for IKE responders (fwd)

[Paul Wouters]

A good summary

Paul

---------- Forwarded message ----------
Date: Sun, 5 Oct 2014 06:25:49
From: Yoav Nir <ynir.ietf at gmail.com>
To: ipsec <ipsec at ietf.org>
Subject: [IPsec] A strategy against DoS/DDoS for IKE responders

Hi

Here are some thoughts about DoS and DDoS protection for an IKE daemon. I think this should be discussed before submitting any drafts, because the acceptance thread reflected that the problem we want to solve is DoS and DDoS, not just the lack of a puzzle mechanism.

If we break down what a responder has to do during an initial exchange, there are four stages:

1. When the Initial request arrives, the responder:
  - generates or re-uses a D-H private part.
  - generates a responder SPI
  - stores the private part and peer public part in a half-open SA database.

2. When the Authentication request arrives, the responder:
  - derives the keys from the half-open SA ([1]).
  - decrypts the request.

3. If the Authentication request decrypts properly:
  - validates the certificate chain (if present) in the auth request

Yes, there's a stage 4 where the responder actually derives keys, but when talking about (D)DoS, we never get to this stage.

Stage #1 is pretty light on CPU power, but requires some storage, and it's very light for the initiator as well. Stage #2 includes private-key operations, so it's much heavier CPU-wise. Stage #3 includes a public key operation, and possibly many of them.

To attack such a server, an attacker can attempt to either exhaust memory or to exhaust CPU. Without any protection, the best avenue is to send multiple faked Initial requests, and exhaust memory. This should be easy because those Initial requests are cheap.

There are obvious ways for the responder to protect itself even without changes to the protocol. It can reduce the time that an entry remains in the half-open SA database, and it can limit the amount of concurrent half-open SAs from a particular address or prefix. The attacker can overcome this by using spoofed source addresses.

The stateless cookie mechanism (that is already in the RFC) prevents an attack with spoofed source addresses. This doesn't solve the issue, but it makes the address or prefix limiting work. Puzzles do the same thing only more of it. They make it harder for an attacker to reach the goal of getting a half-open SA. They don't have to be so hard that an attacker can't afford to solve them - it's enough that they increase the cost of a half-open SAs for the attacker.

Reducing the amount of time an abandoned half-open SA is kept attacks the issue from the other side. It reduces the value the attacker gets from managing to create a half-open SA. So if a half-open SA takes 1 KB and it's kept for 1 minute and the capacity is 60,000 half-open SAs, an attacker would need to create 1,000 half-open SAs per second. Reduce the retention time to 3 seconds, and the attacker needs to create 20,000 half-open SAs per second. Make each of those more expensive, and you're likely to thwart an exhaustion attack against responder memory.

At this point, I'm guessing that this is no longer the most efficient DoS attack. The attacker has two ways to do better:
  1. Go back to spoofed addresses and try to overwhelm the CPU that deals with generating cookies, or
  2. Take the attack to the next level by also sending an Authentication request.

I don't think the first thing is something we can deal with at the IKE leve. It's probably better left to IPS technology.

Sending an Authentication request is surprisingly cheap. It requires a proper IKE header with the correct IKE SPIs, and it requires a single encrypted payload. The content of the payload might as well be junk. The responder has to perform the relatively expensive key derivation, only to find that the Authentication request does not decrypt. Depending on the responder implementation, this can be repeated with the same half-open SA (if the responder does not delete the half-open SA following an unsuccessful decryption). For extra credit, the attacker can send the Authentication request just before the entry expires.

Here too, the number of half-open SAs that the attacker can achieve is crucial, because each one of them allows the attacker to waste some CPU time. So making it hard to make many half-open SAs is important.

A strategy against DDoS has to rely on at least 4 components:
  1. Hardening the half-open SA database by reducing retention time.
  2. Hardening the half-open SA database by rate-limiting single IPs/prefixes
  3. Guidance on what to do when an Authentication request fails to decrypt.
  4. Increasing cost of half-open SA up to what is tolerable for legitimate clients
  5. Other things?

Puzzles have their place as part of #4. I think a WG document should cover all.

Yoav

[1] this could be done in part #1, but that makes the DoS issue worse.
_______________________________________________
IPsec mailing list
IPsec at ietf.org
https://www.ietf.org/mailman/listinfo/ipsec