[ratelimits] RRL vs other approaches

[Roland Dobbins]

Vernon Schryver <vjs at rhyolite.com> wrote:

>Many things that were once Good Enough are no longer Good Enough
>today. 

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>