This is a discussion on Re: stopping amplification - DNS ; # Problem Analysis: # # There are three thorns in folks' side about this. # # 1) The attacks use spoofed source addresses. This ain't something # that can be fixed in the DNS protocol, BCP38(+/-3) be, uh, hanged. agreed. ...
# Problem Analysis:
# There are three thorns in folks' side about this.
# 1) The attacks use spoofed source addresses. This ain't something
# that can be fixed in the DNS protocol, BCP38(+/-3) be, uh, hanged.
# 2) The attacks make use of servers that will answer to arbitrarily
# sourced packets with lots of data. Currently only recursive servers
# can really to this, sooner or later any DNSSEC zone server will
# qualify for this duty.
not agreed. authority servers are also willing to answer arbitrarily sourced
packets with lots of data. and when we close all the open recursive servers,
you can bet that the attacks will change to "pick 50,000 .COM names, find out
who their nameservers are, issue spoofed source query streams for
.COM". recursion isn't the problem. and when DNSSEC makes it
worse, it'll also be worse for authority responses.
# 3) The attacks make use of something called amplification,
# specifically the ability to send a little message in and get a lot of
# message out.
not agreed. the most valuable feature (to an attacker) of the current
setup is that syntactically valid DNS datagrams get sent to UDP/53 on the
victim servers. they can't be firewalled or filtered at line rate inside
the victim's ISP since they look just like the packets that OUGHT to be
delivered. (this distinguishes them from ICMP attacks, which can be
rate limited or filtered far from the servers being attacked.) so,
amplification isn't the problem. amplification is just "gravy."
# Item 2 is something that is rather operations-ish. But is bodes not
# well for protocol developments in the future. Currently the only
# effective amplification that DNS affords is via recursive servers
# caching large data sets. In the future, authoritative servers will
# do so too, via DNSSEC and other means. (The pinata du jour on this
# one is DNSSEC.) (Ooh, English, Spanish, and French.)
since "dig @ns.watson.ibm.com. www.ibm.com a" sends a 29-octet query (plus
UDP and IP headers) soliciting a 130-octet response (plus UDP/IP headers),
i really think we should stop saying that you need DNSSEC to get amplification
from an authority server.
since there are enough authority servers out there, and enough bots available
to stream spoofed-source queries to them, to overload pretty much any victim's
pipe, i think we should also stop saying that amplification is even necessary.
# Item 3 is something that can be dealt with within the protocol. And
# this is what my goofy idea addresses.
# Potential Solution:
# The crux of the goofy idea is that the only way to prevent DNS from
# being an agent of amplification is to make the queries (almost) as
# big as or bigger than the responses. Via padding, of course.
as you said, "yes, this is goofy." but not for the reasons you noted. what's
wrong with this idea is that it solves only the problems we're not having,
while leaving in place all the weaknesses that make today's DNS dangerous and
# Obligatory disclaimer:
# Yes, this is goofy. But, if we want to stamp out amplification, how
# else can it be done? I am willing to accept that "we don't intend to
# stamp out amplification." Or, "is this a long term solution to a
# short term problem?"
# PS - Yes, April 1 is this Saturday. Take that for what it's worth.
since recursion and amplification aren't necessary to the success of this
attack, i think we had better focus on reflection and spoofing. reflection
as in open recursive nameservers. let's force the attackers into using
authority servers for this, and then let's de-mix the mode of the authority
servers so that there's no "authority and recursion in the same server image"
so that authority servers can safely discard any UDP/53 packet from any other
authority server (and from any known-open known-abused recursive nameserver.)
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.