Hi Yoav,
Thanks for this excellent analysis. A few comments:
- When using ECDH, part of the cost of step #2 is validating the
incoming DH public key, per RFC 6989. This assumes you are reusing DH
parameters, which makes sense in a DoS situation. It may be legit (but
strange) to defer this validation to follow the integrity check of the
encrypted payload.
- I'm not sure what is special about "[the case] when an Authentication
request fails to decrypt." Seems to me this is a verified DoS attack
from a specific IP.
- Your model talks about a single gateway, or a tight cluster of
gateways. An advantage of puzzles that goes beyond this model is that
even if your gateways do not share information about suspicious IPs, a
puzzle generated by each gateway reduces the attacker's power to attack
any other gateway. This is much more powerful than rate limiting by any
particular gateway.
Thanks,
Yaron
On 10/05/2014 01:25 PM, Yoav Nir wrote:
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@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
