Opened 12 years ago

Closed 12 years ago

#14 closed defect (fixed)

Large Data in the DNS

Reported by: bernard_aboba@… Owned by: jon.peterson@…
Priority: critical Milestone: milestone1
Component: draft-iab-dns-applications Version: 1.0
Severity: Active WG Document Keywords:
Cc:

Description

I would proposed to add "Large data" to the list of inappropriate uses in Section 5, along with the following text (which might fit in Section 5 or perhaps Section 6):

Storing large amounts of data within DNS RRs represents a potential security threat to the Internet due to reflection attacks. Examples of large data stored currently within the DNS includes certificates [RFC4398].

In a reflection attack, the attacker sends DNS queries with a forged source address, and the victim receives the response. By enabling the DNS to provide large responses to small queries, the bandwidth that an attacker can focus on the victim is magnified. Since a reflection attack can be launched from any network that does not implement source address validation, these attacks are difficult to eliminate absent the ubiquitous deployment of source address validation. Since reflection attacks are most damaging when launched from high bandwidth networks, the implementation of source address validation on these networks is particularly important.

The bandwidth that can be mustered by a botnet controlling broadband hosts is considerable. For example, if magnification of 20:1 is available, then a botnet controlling 1000 hosts, each with 1 Mbps of bandwidth can focus 20 Gbps of traffic on the victim. Since botnets several orders of magnitude larger have been observed, reflection attacks have the potential to congest virtually any existing (or future) Internet link.

Change History (3)

comment:1 Changed 12 years ago by Bernard_Aboba@…

Here is a revised proposal that provides more detail on the potential risks:

Designs relying on storage of large amounts of data within DNS RRs need to minimize the potential damage
achievable in a reflection attack, in which the attacker sends DNS queries with a forged source address, and the victim receives the response. By generating a large response to a small query, the attacker can magnify the bandwidth directed at the victim.

Since it is difficult to complete a TCP three-way handshake begun from a forged source address, DNS
reflection attacks utilize UDP queries. Unless the attacker utilizes EDNS0 [RFC2671] to enlarge the
requester's maximum payload size, a response can only reach 576 octets before the truncate bit
is set in the response. This limits the maximum magnification achievable from a DNS query that does
not utilize EDNS0.

However, where the responder supports EDNS0, an attacker may set the requester maximum payload size to a larger value while querying for a large RR, such as a certificate [RFC4398]. Thus the combination of large
data stored in DNS RRs and responders supporting large requester payload sizes has the potential to increase
the potential damage achievable in a reflection attack.

Since a reflection attack can be launched from any network that does not implement source address validation, these attacks are difficult to eliminate absent the ubiquitous deployment of source address validation. Since reflection attacks are most damaging when launched from high bandwidth networks, the implementation of source address validation on these networks is particularly important.

The bandwidth that can be mustered in a reflection attack directed by a botnet controlling broadband hosts
is sobering. For example, if a responder could be directed to generate a 10KB response in reply to a
50 octet query, then magnification of 200:1 would be attainable. This would enable a botnet controlling 10000 hosts with 1 Mbps of bandwidth to focus 2000 Gbps of traffic on the victim, more than sufficient to
congest any site on the Internet.

comment:2 Changed 12 years ago by bernard_aboba@…

  • Component changed from dns-applications to draft-iab-dns-applications

comment:3 Changed 12 years ago by jon.peterson@…

  • Resolution set to fixed
  • Status changed from new to closed

added

Note: See TracTickets for help on using tickets.