Hi Yoav
This is a subject I've spent way too much time thinking about and is close to my heart. :-) I'm actually surprised a Bot hasn't been used to take down a VPN service using the Auth attack that you describe, or not one that I've heard of. I'd like to add, for 1, if 6989 is employed then I was under the impression this could become a serious issue as these check can be resource intensive, also if a unique DH exchange per session this could considerable increase the workload. Great summary btw, I've included some comments inline GB> cheers On 05/10/2014 11:25, "Yoav Nir" <ynir.i...@gmail.com> 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 GB> From experience the cookie mechanism works very well, I have never seen a need for an IPS or similar. > 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. GB>I'd say this would need to be a number or % of connections, just a single auth failing - we wouldn't want to bring the whole system into some locked down state. For a large number of clients it's common for authentications to fail (from personal experience). > 4. Increasing cost of half-open SA up to what is tolerable for >legitimate clients GB> This 'sweet spot' is crucial, but seems to vary per implementation. > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
