[ratelimits] RRL vs other approaches
rdobbins at arbor.net
Mon Feb 25 04:52:24 UTC 2013
Vernon Schryver <vjs at rhyolite.com> wrote:
>Many things that were once Good Enough are no longer Good Enough
Truncate-mode is used successfully today to mitigate DDoS attacks. The posited corner-case is something I've never observed nor heard of occurring in real life, & requires either a very unlikely coincidence or such an implausible level of attacker knowledge of & control over target behavior as to obviate any possible motivation for a DDoS attack in the first place.
>The old methods should be sneered at when they can be replaced.
When they work well, they shouldn't be replaced, but rather supplemented.
This is a primary difference between theoreticians & implementors/operators - the former are always preaching the virtue of one silver bullet or another, whereas the latter understand the value of having multiple tools/techniques available in the toolbox.
>Some of us sing "Back to the drawing board" with glee instead of
>doom, gloom, or implications that RRL is not deployable.
Nobody on this thread has expressed doom, gloom, or implied that RRL is undeployable, AFAICT. For myself, I think it's an extremely valuable innovation which ought to be widely deployed, & that some of its classification mechanisms ought to be incorporated into other mitigation methods, as well.
>That is because some applications differ from reflection attackers as seen at recursive servers only by not using spoofed source addresses.
Sure. Same for authoritative servers.
>There are many things that BCP38 would fix, but we're talking about
>mitigating DNS reflection attacks instead of those many other attacks.
What I'm talking about is the inaccurate assessment of the validity of truncate-mode as an antispoofing mechanism. The posited risk is negligible, the benefits have been clear for many years, & are clear today. It isn't perfect, but it's useful - and also should be supplemented with newer mechanisms such as RRL.
Actually, the biggest objection to truncate-mode isn't the posited corner-case. Rather, it's the pervasive misfiltering of TCP/53 due to 'security' misinformation which continues to be propagated to this day. In point of fact, there are some sizeable DNS operators who, regrettably, even now filter TCP/53 to their authoritative server farms.
>RRL is for mitigating DNS reflection attacks and not cleaning pipes.
Doing the one tends to have the effect of accomplishing the other. It is a virtuous circle.
>Anyone still toiling at the coal face with picks and shovels has
>at best non-technical reasons for not switching to modern machinery,
>including automation that removes people from the face and that was
>not available 10 or 20 years ago.
It isn't a matter of switching, or of proclaiming older mechanisms which work quite well to be suddenly inadequate due to inaccurate risk assessments. Rather, it's a matter of a) deploying newer mechanisms and b) employing them in a situationally-appropriate manner alongside various other applicable mechanisms - and of improving those other mechanisms, as well.
>In other words, it's silly to suggest that RRL is only theoretical or has only theoretical benefits.
I haven't seen anyone suggest or even imply that on this thread. Again, I think it should be deployed & utilized as widely as possible.
>I'm happy to be wrong; maybe those implementations (including stubs)
It isn't intended for use with stubs. It works well to authenticate recursors against authoritative servers only.
>Then why propose truncate mode as a good, current alternative to RRL?
It is current, it is good, it works pretty well, & it has been deployed & utilized for quite some time.
But I am not proposing it as a replacement for RRL. What I am saying is that truncate-mode is useful, it is not bad or stupid or awful. I am also saying that RRL is a Very Good Thing, & that I wholeheartedly advocate its use.
Roland Dobbins <rdobbins at arbor.net>
More information about the ratelimits