Skip to main content

Amplified DDoS Attacks: The current Biggest Threat Against the Internet

Ddos attack

About a year ago, The Spamhaus Project was victim to what was then considered the worst to date DDoS attack. It directed DNS response traffic at a rate of nearly 300 gigabytes per second against Spamhaus’s name servers flooding them, making them unable to resolve requests for and making appear down to anyone unable to resolve the name.

To do this, the attackers exploited a vulnerability in the Domain Name System (DNS). They directed their attack against DNS resolvers and against the authoritative name servers set up by the registrant (in this case, Spamhaus) for the regular operation of their own domain name. While the threat that this type of attack represents comes from the misuse given by attackers to addressing resources, its mitigation rests in improving address management practices at the network edge (see 1.4, SAC 004 [PDF, 8 KB].)

DNS DDoS Attacks Fundamentals

The attackers used three techniques – IP spoofing, reflection, and amplification – to launch this massive attack against Spamhaus. They coordinated to send extraordinary numbers of DNS queries to around 30,000 DNS servers. In each of these queries, the source address was spoofed or set to the address of Spamhaus’ DNS server. This caused the 30,000 DNS servers to believe that their responses had to be sent to the Spamhaus’ DNS server (reflection). And, to make things worse, the attackers made a DNS query that would cause all the 30,000 DNS servers to reply with a very large response packet (amplification.)

Is there a solution?

Back in the 90s, Paul Ferguson and Dan Senie predicted the enormous potential of harm that IP spoofing represents and published, via the Internet Engineering Task Force (IETF,) a draft of the document that, after a long process and several years of discussion, ended up becoming BCP 38 (What is a BCP?)

BCP 38 describes the solution (or a defense, depending on who you ask) to IP address spoofing: That all Internet service providers and operators of Internet infrastructure implement a technique called Source Address Validation in their servers. If an ISP has implemented BCP38, when it receives an IP packet claiming to come from an IP address that’s not within the range of addresses that have been assigned to it, the ISP would block the packet and not let it through.

BCP38′s implementation

BCP38 greatly reduces the ability to create attacks of such scale as the one launched against Spamhaus. What’s unfortunate is that, although the first draft of the document was published in 1997, the measures have not yet been implemented widely by most ISPs throughout the world.

Because of the low level of implementation of BCP38, I wanted to ask some questions to Paul Ferguson, one of its co-authors, who very kindly shared his view for this post:

Carlos Alvarez (CA): You are one of the 2 authors of BCP38/RFC2827. How frustrating has it been for you that it’s not been widely implemented, although the document was first published so very long ago?

Paul Ferguson (PF): We (my co-author, Dan Senie, and I) actually published the document as an IETF draft in 1997, and it later became RFC2267 in 1998 (what is an RFC?,) obsoleted by RFC2827 in 2000, and later became a BCP (Best Current Practice), specifically BCP38, later in 2000.

How frustrated am I? Only slightly. The Internet is a *very* big thing, and it is not necessarily reasonable to expect complete compliance amongst all participants, especially on an architectural issue which is voluntary, and that is what BCP38 and it’s anti-spoofing recommendations are: voluntary.

Having said that, there is *no* legitimate reason to allow source-spoofed IP traffic on the Internet. Period. Full stop. Networks which allow source-spoofed IP traffic are basically allowing criminal activity within their own networks. We should encourage the entire Internet to embrace S.A.V.E. or Source Address Validation Everywhere.

CA: How do you think we could have all the ISPs and other Internet infrastructure operators implement source address validation? Should we, as some suggest, look for new regulation (Dave Piscitello‘s excellent article on regulation and DDoS attacks can be read here) making it mandatory everywhere?

PF: I would much rather prefer that the ISP community police itself and voluntarily implement these measures instead of governments and legislatures getting involved. We need to do this before someone else tries to force us to do it, and we end up with something draconian or technically impossible.

Having said that, getting ISPs to do this voluntarily does not seem to be working, so perhaps some small amount of legislation or regulation might be needed. I run hot and cold on this issue.

CA: Merike Kaeo (who is Merike?) recently shared that during an event she asked the Finnish why they are so good at BCP38. Their answer was gracious in its transparency: ‘We implemented BCP38 because our regulator said it is a good idea.’ So, if regulation is not the perfect answer, and it of course will never be the solve-it-all solution, should we replace all the employees of every operator of Internet infrastructure with Finnish folks?

PF: With regards to the Internet, I’ve always been of the opinion that “Let a thousand flowers bloom” is the appropriate attitude. We welcome diversity, and we should embrace it. But at the same time we should also embrace the idea of a CDC (Center for Disease Control) model for the Internet Infrastructure. If we all don’t agree to some basic guidelines to support the health of the Internet, someone may come along and simply burn it down as they like, and that’s what these DDoS attacks represent.

Some recommendations regarding Source Address Validation

Paul Vixie (who is Vixie?), in a conversation he recently had with a reporter, made some suggestions on how to seek wider implementation of BCP38 that can be worth discussing, such as including civil penalties for contributory negligence when a non-Source Address Validated network is used as a DDoS launch point that causes harm, and ISO 9000 or 27000 terms of reference for this, so that buying insurance is harder if networks are not doing Source Address Validation.

To complete these, it is necessary to make reference to the document SAC065 [PDF, 423 KB], published by ICANN‘s Security, Stability and Resiliency Advisory Committee, that contains recommendations that should be adopted by all ISPs and Internet infrastructure operators all around the globe.

I asked Vixie if he could write some lines to the ISPs and Internet infrastructure operators in Latin America. I extracted these, that are applicable to folks all around the world: “Source Address Validation is a little more work for network operators, but the downstream benefit for the overall economy and for human society is well worth that extra work.”


Hopefully the ISP industry and all the other operators of Internet infrastructure will soon implement – voluntarily – Source Address Validation. If they don’t, the frequency and size of the DDoS attacks will continue to grow, increasing the likelihood of regional Internet blackouts, and increasing the likelihood that national governments enact regulations that may not necessarily be operationally or technically desirable.

Special thanks to Vixie and Fergie for their kind contributions to this article.

Greetings from California,

Carlos S. Alvarez
SSR Technical Engagement Sr. Manager
Security Stability Resiliency Team


    Domain Name System
    Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as"""" is not an IDN."