In March 2013, Spamhaus was hit by a significant DDoS attack that made its services unavailable. The attack traffic reportedly peaked at 300Gbps with hundreds of millions of packets hitting network equipment on their way. In Q1 2015, Arbor Networks reported a 334Gbps attack targeting a network operator Asia. In the same quarter they also saw 25 attacks larger than 100Gbps globally.

What is really frightening about this is that such attacks were relatively easy to mount. Two things made these attacks possible: bots with the ability to spoof the source IP address (setting it to the IP address of a victim) and "reflectors" — usually open DNS resolvers. A well selected DNS query can offer a 100-times amplification, meaning that one needs only to generate queries totalling 3Gbps to create a merged flow of 300Gbps. A relatively small set of clients can accomplish this.

Of course there are DDoS attacks that do not use these two components; they hit the victim directly from many globally distributed points. But they are traceable and two orders of magnitude more difficult and expensive to accomplish.

Mitigating the reflection component of the attack is one way of addressing the problem. As reported by the OpenResover project, in the last two years the amount of open DNS resolvers has dropped almost by half — from 29M to 15M. However, there are other types of amplifying reflectors — NTP and SSDP are among them, and even TCP-based servers (like web servers, or ftp servers) can reflect and amplify traffic.

And reflectors are just the accomplices. The root cause of the reflection attacks lies in the ability to falsify, or spoof, the source IP address of outgoing packets. As Paul Vixie put it, "Nowhere in the basic architecture of the Internet is there a more hideous flaw than in the lack of enforcement of simple SAV (source-address validation) by most gateways."

Tackling this problem is hard. Lack of deployment of anti-spoofing measures is aggravated by the fact that the implementation of anti-spoofing measures is often incentive-misaligned, meaning that networks only help other networks by implementing the practice and do not directly help themselves. There are also real costs and risks for implementing anti-spoofing measures.

In February 2015, a group of network operators, security experts, researchers and vendors met at a roundtable meeting organized by the Internet Society with a goal to identify various factors that aggravate or help solve the problem, and to identify paths to improve the situation going forward.

The main conclusion is that there is no silver bullet to this problem and if we want to make substantive progress it has to be addressed from many angles. BCP38, which is sometimes promoted as *the solution* to the problem, — is just one tool, not effective in some cases. Measurements, traceability, deployment scenarios and guidance, as well as possible incentives, communication and awareness — are among the areas identified by the group where positive impact should be made.

For example, measurements and statistically representative data are very important; if we want to make progress, we need to be able to measure it — the ability currently missing to a great extent.

Another recommendation that came out of this meeting was the possibility of anti-spoofing by default. The only place you can really do anti-spoofing is the edge (or as close as possible). Addressing the challenge at the edge seems only possible with automation and if anti-spoofing measures are switched on by default.

Read more about this in a whitepaper that contains the main takeaways from that discussion and articulates possible elements of a comprehensive strategy in addressing source IP address spoofing challenge.

I ask you to read the whitepaper, and ultimately deploy these anti-spoofing technologies in your own network. Can you do your part to prevent DDoS attacks? And if you are willing to do your part, how about signing on to the Mutually Agreed Norms for Routing Security (MANRS) and joining with other members of the industry to make a more secure Internet?

This post was previously published on the Internet Society's blog.