[ratelimits] RRL vs other approaches

[Dobbins, Roland]

On Feb 24, 2013, at 11:24 PM, Paul Vixie wrote:

> we must not attempt reason from the specific to the general in the way you're implying here, if the details aren't endemic. that is, since the bad guys can easily change from ANY to some other qtype, we won't widely deploy a defense against ANY; similarly, since the bad guys can easily choose a recursive dns server which shares upstream capacity with their real target, we won't widely deploy a solution that only works if their proximate and direct target is not a recursive dns server.

I'm not; I'm just pointing out that a) the corner-case posited is just that, a corner-case, and b) that it doesn't even apply as a corner-case to the vast majority of attacks we've seen, to date.

I believe that the more generalizable a specific protection methodology is, the more useful it is.  We're in violent agreement.

> the topic under discussion is not what will work on a case by case basis, but rather what can we globally deploy that will make the whole system harder to successfully attack.

Sure, and I agree that RRL is the sort of strategic change necessary to make the system as a whole more resilient.  I just don't think it's helpful to make untrue generalizations about specific defense methodologies which in fact do work pretty well in practice, and which anyone can implement, if he so chooses, since they aren't the sort of thing which can be encumbered with any intellectual property claims.

> and which would not work if the bad guys had no lower-hanging fruit and instead had to focus their bypass efforts on your specific methods.

Again, they would work pretty well unless the ultimate end-target of an attack happened to be a specific resolver which was querying a specific authoritative server and was covered by a system forcing truncate-mode.  This presupposes a level of attacker insight into and control over the behavior of the target as to beggar belief.

What I'm saying is don't condemn S/RTBH because it's only layer-3; don't condemn flowspec because it's only layer-4 and Cisco have yet to implement it, though it's finally coming; and don't condemn truncate-mode as an anti-spoofing mechanism, because it's worked pretty well for 11 years and works pretty well today.  It isn't necessary to unduly criticize mitigation mechanisms which have proven useful in the field, are useful today, and will be useful tomorrow, in order to promote RRL.

More behavioral modeling and ability to exert control over transaction flow in servers in general is a Very Good Thing.  My hope is that it will be adopted more generally by other common server types.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

	  Luck is the residue of opportunity and design.

		       -- John Milton