I've been urged to send out this proposal, which even I think is rather goofy.

Problem statement:

Recently, there has been a lot of hub-bub about the use of recursive
servers to amplify traffic sent in a DDoS attack.

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.

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.

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.)

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.

That would enable this: I could require that such a query be padded
up to the size in the EDNS0 field before I'll deal with it? I know
it's goofy to send the extra, useless bytes, but what's more
important? Smaller messages or stopping the "baddies" out there?

The proposal is to add an optional padding field to EDNS0.5 to allow
for padding. A server operator *could* then have a policy that says:
answer up to the lesser of the EDNS0 size field and the size of the
query. Or, if the query is smaller than the EDNS0 size field, answer

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.
Edward Lewis +1-571-434-5468

Nothin' more exciting than going to the printer to watch the toner drain...

to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.