It was reported that IKE/IKEv2 protocol is vulnerable to DoS amplification attack.
Some comments: "The first is that a proper IKE_SA_INIT packet will result in an unknown number of packets from the responder over an unspecified period of time." This is incorrect. IKEv2 responders _never_ retransmit. So for each received IKE_INIT request it will send at most one IKE_INIT response. Which you noticed too: "A majority of these (3.9 million) only replied with a single packet" Next: "The second is that the responder is expecting abuse and will not maintain any state related to unauthenticated peers. What this tells us in theory is that IKE infrastructure as designed might be susceptible to abuse for the sake of reflection and amplification DDoS attacks." I do not understand this remark. Any server exposed to the internet should be designed against DDoS attacks. The IKEv2 protocol does this very well. libreswan supports this with various ddos- options that can be tweaked when needed, but provides sane defaults. Next: "These standards say that the sender of a packet should set a timer and a counter, and upon failure of a response packet, they should attempt a packet retransmission. These retransmissions should be sent using an exponential backoff and should continue retransmission until the counter is exhausted or a reply is received." That is clearly only valid for IKEv1. For IKEv1, we use exponential back-off. In all openswan versions this was 20s, 40s, 60s, 60s... For libreswan this is 0.5s, 1s, 2s, 4s, 8s, 16s. The timeout for openswan was 5 minutes, for libreswan it is 30 seconds. "ultimately triggering an amplification ranging from 2% to 7,933%" These numbers of out real context, don't mean much. "In this traffic sample a host configured to respond 10 times was targeted at random of all 10 count hosts, it was sent a packet with a randomized SPI every .1 seconds for a total of 100 packets. " This makes no sense. You configured a host to reply 10 times? Well, that's not a valid IKEv2 host then, so your custom protocol can amplify 10 times? "The easiest and suggested way to mitigate this attack would be a blanket policy dropping all inbound UDP traffic sourcing from port 500 where possible." That would be blocking legitimate IKE traffic. Why would you do that? It would break any device attempting to use IKE/IPsec. "If the affected machine is another IKEv2 node that requires port 500 be open for operational purposes rate limiting that ultimately leads to blocking would be the next best option." "A rate limiting strategy is recommended," See "man ipsec.conf" and look for ddos-mode, ddos-ike-treshold and max-halfopen-ike "However, we also know that a single request can trigger multiple responses over fairly long windows of time" Not for openswan/libreswan. Especially not in IKEv2. "Another option and likely more successful strategy would be utilizing outbound ratelimiting and dropping outbound traffic. Preferably both of these measures could be combined to help prevent your infrastructure from being leveraged for DDoS abuse. " Nothing should be done outside of /etc/ipsec.conf configuration. And even there the defaults are very sane. " In their current state we believe they could be leveraged to attack those same businesses and organizations around the Internet with crippling success." I suggest you take it up to the IETF to obsolete the UDP protocol and find a replacement with the same features we need from UDP that lacks the downsides of UDP. I wish you good luck :) I would like to close this bug as WONTFIX
Public via: https://www.kb.cert.org/vuls/id/419128 https://blogs.akamai.com/2016/02/ikeikev2-ripe-for-ddos-abuse.html
Statement: This is a protocol flaw which affects IKEv1. All complaint implementations are therefore affected by this flaw. Red Hat Product Security team, does not consider IKEv2 to be affected. For more details please refer to https://bugzilla.redhat.com/show_bug.cgi?id=1308508#c2
Re-opening, I'll write upa blog post on this. We are considering one update to libreswan IKEv1 to reduce amplification caused by retransmits: https://lists.libreswan.org/pipermail/swan-dev/2016-March/001394.html For IKEv2, there is no such issue (and IKE_INIT response is smaller than IKE_INIT reply message.
This is tracked via upstream bug: https://bugs.libreswan.org/show_bug.cgi?id=262
Upstream commit: https://github.com/libreswan/libreswan/commit/152d6d95632d8b9477c170f1de99bcd86d7fb1d6
Created libreswan tracking bugs for this issue: Affects: fedora-all [bug 1344566]
CVE request: http://seclists.org/oss-sec/2016/q2/515
note this is fixed in libreswan 3.17
CVE assignment: http://seclists.org/oss-sec/2016/q2/518 This CVE is specifically for the issue in libreswan, as confirmed by Mitre: "Use CVE-2016-5361 for this issue only in the libreswan codebase."
The issue is a protocol issue, not a libreswan code implementation issue.
Please remove this CVE immediately. That is not a security vulnerability in libreswan.
(In reply to Tuomo Soini from comment #14) > Please remove this CVE immediately. That is not a security vulnerability in > libreswan. Hi Tuomo, Please talk with MITRE about this (They assigned the CVE!). If you note comment #10, i actually asked for a CVE pertaining to the IKE protocol flaw, rather than its implementation.
Redhat security requested this CVE - you should admit your mistake and request removal. Please contact security before requesting CVE:s for libreswan. This is not first total bogus cve requested by redhat security and you should not request these without contacting us. Tuomo Soini, The Librewan Project
IKEv2 is reported to be affected as well: http://seclists.org/oss-sec/2016/q3/23
See my reply on the list. I think those are most likely IKEv1 only implementations using the incoming ISAKMP haeder to build a reply packet.
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2016:2603 https://rhn.redhat.com/errata/RHSA-2016-2603.html
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2016-5361