In message <51b9fb6a.1090...@tiggee.com>,
David Miller <dmil...@tiggee.com> wrote:
>This could lead to wrong headed statements like, "Yes, we sent X GB of
>traffic at your network.
Yes.
Last night I reconsidered at some length the scheme I put forward yesterday.
(Please note that I am very deliberately calling it merely a "scheme"
rather than a "proposal", because I do not think that it rises to the
level of that honorable title yet.)
Basically, please ignore everything I put forward yesterday and substitute
instead the following in place of all that...
1) A new DNS/UDP packet/message type is defined. This new message
when sent from from machine A to machine B informs B that A would
really really appreciate it if B would cease and desist from sending
anything other than HIGHLY ABBREVIATED (12 byte) UDP DNS response
packets to the IP address of A for a period of 30 seconds. (Said
highly abbreviated DNS/UDP response packets would all have the TC
bit set.)
In a hypothetical revised future DNS RFC it would be said that all
DNS servers attached to the public internet MUST be capable of
properly receiving, decoding and obeying any and all such client
requests.
2) A new DNS/TCP packet/message/interaction is defined. A given machine
at IP address `A' (which may or may not even be a DNS server or
client) may connect to a DNS server at IP address `B' and may
execute a transaction with `B' which requests that the DNS server
running on `B' should refrain from sending any DNS/UDP response
packets to `A' for a period of time encoded within the interaction.
Again, hypothetically, in future this would be a "MUST".
In its response to A's request, B would include the number of seconds
since the last time that B received a DNS query *via UDP* that was
ostensibly from A.
The first provision above is the fast-reaction emergency stop-gap. It can
be sent out even when the DDoS target is already undergoing/experiencing a
massive packet inflow. (It _is_ only one small _outgoing_ packet after all,
so the DDoS victim should, be able to squeeze that out, I think. After all
is is only the inbound side of the connection that is getting DDoS'd.)
The second provision above is what you do after you have sent the emergency
stop-gap "panic button" UDP "Stop killing me!" packet/request. By this
time, things will have hopefully settled down a bit, at least enough for
the victim to be able to complete a three-step TCP handshake _and_ get a
single small additional payload packet out via the TCP connection.
As mentioned in my previous scheme, the information that comes back from
B (i.e. one of the unwitting DNS servers that are participating as
amplifying intermediaries in the attack) regarding the amount of time
that has elapsed since _it_ last received an attack packet (i.e. any
spoofed DNS query appearing to have come from A) will help A decide
when the time is ripe for it,the victim, machine, to come out of the
bunker and crawl back into the sunlight.
Note that _by definition_ exactly and only any *UDP* DNS query packet that
B has received since A told it... via secure TCP connection... that it
would stop sending any DNS queries to B via UDP for awhile... and that
thus, B should stop sending any DNS/UDP _responses_ to A for that same
"awhile"... are, by definition, forged/spoofed DNS queries. So each time
any participating intermediary DNS server `B' receives a DNS/UDP query,
it should merely look to see if the apparent source IP `A' is currently
present in the (hopefully VERY small) list of IPs that B is currently
in "safe interaction mode" with, and if B finds A's IP in that VERY
small list, then it merely grabs the current system second-since-epoch
clock value an then uses that to update the most_recent_spoof_time field
of the trivially simple two-word (64 bit) record corresponding to that
specific current "safe mode" client, `A'. Only two 32-bit words should
be needed for each (IPv4) "safe mode" client that has properly requested
a switch to "safe mode" from B, i.e. (1) A's 32-bit IPv4 address and (2)
the 32-bit most_recent_spoof_time field.
Trivial, no?
Yea, yea. OK... so yes, those records have to be bigger than 64-bits in
cases where the specific safe-mode client is speaking IPv6. No biggie.
Let's not get bogged down in quibbling about minor and inconsequential
trivialities.
Regards,
rfg
P.S. I envision the new packet types for (1) above could be defined as
simply as possible, so that even things other than (and simpler than)
full-blown DNS servers could send them... maybe even... um... routers.
Twelve bytes of all zeros ought to do it. (Can't get much simpler than
that!) Unless I am mistaken, that ought to be entire orthogonal to any
and all actual/ordinary DNS packets, at least at present.
P.P.S. Yes, yes, I _am_ aware... as someone will surely point out...
that part (1) above contains the seed of potential abuse. A malicious
prankster could, in theory send spoofed packets of type (1) above to
lots and lots of DNS servers which he believes that his real victim, A,
might be needing to send legitimate DNS/UDP queries to... and needing
to get legitimate DNS/UDP queries back from... in the near/immediate future.
But what is the absolutely worst case that might occur, even if this were
done at some really massive level against some victim `A'? The worse
case effects of this this bizzare and back-handed new kind of Denial of
Service attack would simply and only be to cause the victim `A' to have
to retry its queries with many of the other servers it is sending legitimate
requests to using TCP rather than UDP... and *only* for an *extremely*
limited period of time.
Even if a determined attacker somehow (via an incredible and unprecedented
feat of mind-reading) managed to figure out the _complete_ set of _all_
other DNS servers in the entire Universe that the victim machine `A' might
ever in future want or need to get a legitimate DNS response from, _and_
even if this hypothetical determined attacker were to send an almost endless
stream of forged/spoofed UDP "please switch to safe mode when talking to me"
packets to 100% of those other DNS servers, continuously, for eternity,
then the worst thing that happens as a result of all that to the victim,
A, is that A if forced to perpetually use TCP rather than UDP to make all
of its subsequent DNS requests... at least for as long as the lame dumb-ass
attacker continues to perpetuate this silly and largely ineffective "DoS"
(although it can hardly even be called that, since service to A is never
"denied"... it is mearly degraded to TCP rather than UDP).
This is an example of "graceful degradation". In my opinion, even this
highly unlikely scenario is still vastly preferable to the current state
of affairs, wherein essentially anybody lacking in well-heeled big-time
(anycast) friends can be blasted to smithereens at virtually any moment
of the day or night, by anonymous strangers, for some reason or even for
no apparent reason, continuously and, potentially, perpetually.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
