Bug 1308508 - (CVE-2016-5361) CVE-2016-5361 IKEv1 protocol is vulnerable to DoS amplification attack
CVE-2016-5361 IKEv1 protocol is vulnerable to DoS amplification attack
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
: Reopened, Security
Depends On: 1344566 1344567
Blocks: 1308512
  Show dependency treegraph
Reported: 2016-02-15 07:32 EST by Adam Mariš
Modified: 2016-11-06 00:37 EDT (History)
5 users (show)

See Also:
Fixed In Version: libreswan 3.17
Doc Type: Bug Fix
Doc Text:
A traffic amplification flaw was found in the Internet Key Exchange version 1 (IKEv1) protocol. A remote attacker could use a libreswan server with IKEv1 enabled in a network traffic amplification denial of service attack against other hosts on the network by sending UDP packets with a spoofed source address to that server.
Story Points: ---
Clone Of:
Last Closed: 2016-03-14 02:39:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Adam Mariš 2016-02-15 07:32:52 EST
It was reported that IKE/IKEv2 protocol is vulnerable to DoS amplification attack.
Comment 2 Paul Wouters 2016-02-16 16:15:50 EST
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"


"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.


"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 back­off 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 rate­limiting 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
Comment 4 Huzaifa S. Sidhpurwala 2016-03-14 02:39:07 EDT

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
Comment 5 Paul Wouters 2016-03-14 07:05:33 EDT
Re-opening, I'll write upa blog post on this.

We are considering one update to libreswan IKEv1 to reduce amplification caused by retransmits:


For IKEv2, there is no such issue (and IKE_INIT response is smaller than IKE_INIT reply message.
Comment 6 Huzaifa S. Sidhpurwala 2016-06-10 00:25:04 EDT
This is tracked via upstream bug:

Comment 7 Huzaifa S. Sidhpurwala 2016-06-10 00:33:24 EDT
Upstream commit:

Comment 8 Huzaifa S. Sidhpurwala 2016-06-10 00:50:44 EDT
Created libreswan tracking bugs for this issue:

Affects: fedora-all [bug 1344566]
Comment 10 Huzaifa S. Sidhpurwala 2016-06-10 01:15:43 EDT
CVE request:

Comment 11 Paul Wouters 2016-06-10 09:32:34 EDT
note this is fixed in libreswan 3.17
Comment 12 Andrej Nemec 2016-06-10 10:05:51 EDT
CVE assignment:


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."
Comment 13 Paul Wouters 2016-06-10 10:32:12 EDT

The issue is a protocol issue, not a libreswan code implementation issue.
Comment 14 Tuomo Soini 2016-06-10 11:11:03 EDT
Please remove this CVE immediately. That is not a security vulnerability in libreswan.
Comment 15 Huzaifa S. Sidhpurwala 2016-06-13 00:23:06 EDT
(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.
Comment 16 Tuomo Soini 2016-06-13 01:18:00 EDT
Redhat security requested this CVE - you should admit your mistake and request removal.

Please contact security@libreswan.org 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
Comment 18 Martin Prpič 2016-07-08 02:48:12 EDT
IKEv2 is reported to be affected as well:

Comment 19 Paul Wouters 2016-07-08 04:17:43 EDT
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.
Comment 22 errata-xmlrpc 2016-11-03 17:22:46 EDT
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

Note You need to log in before you can comment on or make changes to this bug.