By Bill Brenner, Akamai SIRT senior tech writer
Akamai's Security Intelligence Research Team (SIRT) is conducting research into the security posture of the Internet Key Exchange (IKE & IKEv2) protocol. The paper outlines the findings thus far, including configurations in the protocol itself that attackers could potentially leverage to launch reflected DDoS campaigns.
Our motivation to examine it is based on the nearly ubiquitous nature of IKE/IKEv2, which is used to facilitate secure key exchanges between peer devices in the IPsec protocol suite. It is widely deployed in multiple secure tunneling applications such as VPN products from major vendors and open source projects.
Given its heavy use, it made sense to take a look under the hood.
Several UDP protocols have appeared on our radar during more than four years of active monitoring and advisory releases concerning reflection-based DDoS attacks. Results yielded from this research have gone into Akamai's State of the Internet Security reports supporting active trends in the DDoS threat landscape.This history has sparked efforts internally to help discover potential UDP based reflection and amplification opportunities, with the goal of disclosing, cleaning up, and fixing issues before they can be weaponized for DDoS.
This is our first piece of research in this regards and is dedicated exclusively to discoveries in IKE/IKEv2. What follows is what we learned after setting our sites more intently on the protocol.
The full paper, available here, delves into the history of IKE, offers visuals to illustrate where the weaknesses are and offers steps organizations can take to reduce risk exposure.
By Bill Brenner, Akamai SIRT Senior Tech Writer
During the past few quarters, Akamai has observed and successfully mitigated a large number of DNS reflection and amplification DDoS attacks abusing Domain Name System Security Extension (DNSSEC) configured domains.
As with other DNS reflection attacks, malicious actors continue to use open DNS resolvers for their own purpose -- effectively using these resolvers as a shared botnet. This technique has also been linked to the DDoS-for-hire underground market.
The attacks are outlined in a new Security Bulletin written by Akamai SIRT, the full report can be downloaded at the following link: http://www.stateoftheinternet.com/dnssec-attacks
DNSSEC is a suite of Internet Engineering Task Force (IETF) specifications for security certain information provided by DNS. It is essentially a set of extensions to DNS which provide origin authentication of DNS data, data integrity, and authentication denial of existence. These additional security controls are designed to protect the Internet against certain types of attacks. A list of all RFCs associated with DNSSEC can be found here: http://www.dnssec.net/rfc
To date Akamai has observed several domain names utilized for these attacks. Although the domains listed in the bulletin have been used in these attacks, other domains can be utilized.
Since the beginning of November 2015, Akamai has detected and mitigated more than 400 DNS reflection/amplification DDoS attacks using a variety of domain names implementing DNSSEC. DNSSEC prevents the manipulation of DNS record responses where a malicious actor could potentially send users to its own site. This extra security offered by DNSSEC comes at a price as attackers can leverage the larger domain sizes for DNS amplification attacks.
Here's a breakdown by Industry vertical of DDoS attacks mitigated against the DNSSEC reflection method between Q4 2015 - Q1 2016:
The highlighted domain has been observed in DDoS attacks against customers in multiple verticals over the same time period, and based on our investigations we believe these attacks are most likely the work of attackers making use of a DDoS-for-Hire service that uses purchased VPS services, public proxies, a classic botnet and basic attack types such as DNS reflection attacks, SYN floods, UDP floods, SSDP floods, NTP floods, ICMP floods and even HTTP GET floods.
The report goes into detail about individual attacks, including screenshots and other graphics, and outlines steps organizations can take to protect themselves.
The full Security Bulletin can be accessed at http://www.stateoftheinternet.com/dnssec-attacks
When it comes to compression on the web, GZIP reigns supreme. In the 18 years since GZIP was first supported by browsers, other compression methods have been introduced but none have matched GZIP's combination of speed, support and results.
Brotli, the compression algorithm Google released as open-source back in September, may soon change that. Chrome (version 49, due in early to mid March) will be shipping with Brotli support, and Firefox (version 44) already has it. Particularly given Chrome's significant reach on the Android platform, this means that Brotli support will go from zero to sixty in no time--bringing reduced file sizes along with it.
To get a better understanding of just how big those savings could be, and what the trade-offs are, we ran a few independent experiments.
Testing the Top 1000 URL's According to HTTP Archive
For the first set we took a list of the top 1000 URL's on the web (pulling the list from HTTP Archive) and downloaded the HTML for each page, as well as all JavaScript and CSS assets. For each asset, we recorded the original weight. We then recorded the weight of the asset with GZIP applied, as well as the weight of the asset with Brotli applied. We kept the quality level of each to the default provided on each tool. We did not unminify any assets, but we did uncompress those who were pre-compressed with GZIP.
HTML
| Median GZIP Savings | 78% |
| Median Brotli Savings | 82% |
| Brotli Improvement over GZIP, Median | 21% |
| Brotli Improvement over GZIP, 90th percentile | 39% |
Javascript
| Median GZIP Savings | 63% |
| Median Brotli Savings | 68% |
| Brotli Improvement over GZIP, Median | 14% |
| Brotli Improvement over GZIP, 90th percentile | 26% |
CSS
| Median GZIP Savings | 79% |
| Median Brotli Savings | 82% |
| Brotli Improvement over GZIP, Median | 17% |
| Brotli Improvement over GZIP, 90th percentile | 27% |
The results are really promising! All three types of resources--HTML, JS and CSS--saw significant savings from using Brotli instead of GZIP.
NOT SO FAST
We can't judge a compression algorithm purely by the amount of bytes saved, however. If we could, GZIP would've been dethroned long ago. Another major consideration is the compression speed: how long does it take to perform the actual compression.
There's a fair amount of chatter about Brotli being much slower than GZIP. And on the surface it is. Run a benchmark on your machine using the default settings of GZIP versus the default settings of Brotli and you'll see the Brotli is much, much slower.
But the key phrase there is "default settings".
GZIP has nine quality levels. If you run GZIP using a quality setting of "1", you won't get a lot of file savings, but the compression will occur incredibly quickly. If you run GZIP using a quality setting of "9", you'll maximize your file savings, but the process will be quite slow. GZIP uses a default setting of "6": it provides a nice blend of file savings and compression speeds.
Brotli has eleven quality levels. Just like GZIP, a quality of "1" is very fast but less effective, whereas a quality setting of "11" is very slow but provides big savings in file size. While GZIP's default setting has been chosen to provide a balance of speed and compression; Brotli's default setting has not. Out of the box Brotli runs on a setting of "11" meaning you get a huge savings in data, but a much slower compression speed.
By playing around with the quality setting on Brotli, you can find a much safer balance.
To get a better idea of where that magic setting is, we looked at the HTML for the top 1000 sites.
We compressed each file individually at different settings of Brotli and GZIP to see what the results would be. For each setting, we ran the compression 20 times and recorded the median speed. The tests were run on a MacBook Air to make it easier to see the impact the settings had on the compression rate. These compression speeds are going to be slower than if you ran them on a more powerful machine. The results (sorted by throughput) are below.
We've highlighted GZIP's default settings in bold, as well as the Brotli setting that had a comparable speed.
| Compression Method | Savings | Throughput, Median | Difference in Speed from GZIP Default | Difference in Size from GZIP Default |
| GZIP (1) | 78.4% | 88.2 MB/s | 128% | -19% |
| GZIP (2) | 79.1% | 84.6 MB/s | 119% | -15% |
| Brotli (1) | 80.9% | 83.2 MB/s | 115% | -5% |
| GZIP (3) | 79.6% | 76.5 MB/s | 98% | -12% |
| Brotli (2) | 82.5% | 71.5 MB/s | 85% | 4% |
| Brotli (3) | 82.7% | 66.1 MB/s | 71% | 5% |
| GZIP (4) | 80.8% | 53.4 MB/s | 38% | -5% |
| Brotli (4) | 83.4% | 47.0 MB/s | 21% | 9% |
| GZIP (5) | 81.4% | 45.6 MB/s | 18% | -2% |
| GZIP (6) | 81.8% | 38.7 MB/s | 0% | 0% |
| GZIP (7) | 81.8% | 31.0 MB/s | -20% | 0% |
| Brotli (5) | 84.5% | 26.4 MB/s | -32% | 15% |
| GZIP (8) | 81.9% | 23.9 MB/s | -38% | 1% |
| GZIP (9) | 81.9% | 20.9 MB/s | -46% | 1% |
| Brotli (6) | 84.8% | 17.1 MB/s | -56% | 16% |
| Brotli (7) | 85.2% | 10.4 MB/s | -73% | 19% |
| Brotli (8) | 85.3% | 8.0 MB/s | -79% | 19% |
| Brotli (9) | 85.4% | 5.8 MB/s | -85% | 20% |
| Brotli (10) | 86.8% | 2.7 MB/s | -93% | 27% |
| Brotli (11) | 86.8% | 2.6 MB/s | -93% | 27% |
There were a few interesting takeaways from the speed test. The first, is that GZIP certainly plateaus in terms of improvement around a quality setting of "6". It's unsurprising then that "6" was chosen as the default.
Brotli has an early peak around a quality setting of "7", but then once you hit "10" it leaps forward again. This leap also corresponds with a significant decrease in speed. Changing the quality setting from "10" to "11" provides no improvement here, nor was improvement seen when testing a handful of individual files to verify the results.
As you can see from the results, if you tweak the Brotli settings a little bit, the compression speeds can actually surpass the speeds of GZIP while still providing some significant savings. Based on these 1000 HTML files, running Brotli at a setting of "4" would not only save more bytes than GZIP's default setting, but it would compress about 21 percent faster as well. That same setting--"4"--showed up consistently as the break-even point when tested on individual files as well.
This is great news as it means that if the defaults are carefully tuned, Brotli could be a suitable replacement for GZIP compression of both static and dynamic assets.
Testing Akamai URL's
In another test, we took 100 domains on the Akamai platform and downloaded the HTML, CSS, JS, XML and JSON files. For each file, we applied GZIP at its highest level of compression (9), as well as Brotli at its highest level (11). The improvements were similar to our prior experiment with the median showing an improvement of 16% and the 90th percentile showing an improvement of 27%.
| Percentiles | 50% | 60% | 70% | 80% | 90% | 95% | 99% |
| Brotli improvement vs GZIP | 17% | 18% | 19% | 22% | 27% | 33% | 58% |
In this experiment, we decided to remove all files smaller than 1KB to see the impact the size of the file had on the compression results. After doing this, Brotli still showed an improvement over GZIP, but it was slightly less pronounced.
| Percentiles | 50% | 60% | 70% | 80% | 90% | 95% | 99% |
| Brotli improvement vs GZIP | 16% | 17% | 18% | 20% | 23% | 26% | 31% |
While it's clear that the smallest files are the ones seeing the highest benefit from Brotli, the impact is still very noticeable.
And your point is?
Brotli isn't quite the revolutionary jump forward that a technology such as HTTP/2 is, but we should welcome every chance to save bytes on the wire. As far as website owners are concerned, it's virtually a flip of the switch that can result in anywhere from 14-39 percent file savings on text-based assets when running full-blast.
Though Brotli slows down the higher the compression setting, it's entirely possible to trade-in some of those bytes for a faster compression setting. If you're going to replace GZIP for compression of dynamic assets, a Brotli quality of "4" is a good place to start. If you're running it ahead of time and queuing up those resources for a later request, then run it full blast and watch the bytes fade away.
Given that images dominate the weight of pages today, you shouldn't expect Brotli to be a magical fix-all for your performance woes. Still, 14 percent savings on text-based assets is nothing to sneeze at--particularly given that it is these text-based assets that stand in the way of the critical path. As sites continue to steadily increase in weight and complexity, any improvement is one worth considering.
