<html><head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head><body style="font-family: tt; font-size: 11pt;" bgcolor="#FFFFFF"
text="#000000"><div style="font-size: 11pt;font-family: tt;"><br><br>Colm
MacCárthaigh wrote:<blockquote
cite="mid:CAAF6GDcEa_-pvD03cJz4PdJ=oTA_Tr2T6wAKiteTNZJ2R8PLyg@mail.gmail.com"
type="cite"><div dir="ltr"><br><div class="gmail_extra"><div
class="gmail_quote">On Fri, Feb 7, 2014 at 9:35 AM, Paul Vixie <span
dir="ltr"><<a moz-do-not-send="true" href="mailto:paul@redbarn.org"
target="_blank">paul@redbarn.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">Colm MacCárthaigh wrote:</blockquote><br><div><br></div><div> >
Now if I have a botnet or client that can generate 1M PPS (this is</div><blockquote
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex"><div class="">
> small, but adjust to any number), I can try to spoof 66,666 popular<br>
> resolvers (this is a knowable set) at 5 QPS each to 3 auth servers,
I<br>
> can use RRL to degrade service in a more widespread way.<br>
><br>
> Now, let's say you have the capacity to answer these queries (which
is<br>
> realistic for some) which behavior is better for your users? Just<br>
> answering the responses? Or rate-limiting the responses?<br>
<br>
</div>Rate limiting is always better, given that recursive servers will
retry,<br>
will act on TC=1, and will stop asking once they cache the result.<br></blockquote><div><br></div><div>Just
to be clear; you're saying it's better, for your legitimate users, only
to answer their queries probabilistically? I agree that they'll retry,
and with 2 retries they'll even get a TC=1 87.5% of the time. But I have
to consider that some kind of degradation of service. For the 12% who
got no answer, do you consider that some kind of degradation?</div></div></div></div></blockquote><br>since
you've asked for clarity, let me provide it as follows.<br><br>for the
case of an attack against the name server itself, not a reflection
victim via ddos but a pool of response-starvation victims via a logic
attack on RRL itself, it is theoretically worse for the
response-starvation victims to have RRL deployed. i say "theoretically"
because the impact would be (a) exceedingly brief, (b) exceedingly
narrow, (c) not user-visible, and must be (d) exquisitely and
expensively well targeted. in this one corner case, my statement "always
better" is wrong.<br><br>for the case of an attack against a reflection
victim via name server reflected DDoS, the impact on
response-starvation victims due to the RRL logic, will be no worse than
the impact of not having RRL, and if the attack is large, it will be
better with RRL than without. therefore my statement "always better"
should have been written "never worse" and i apologize.<br><br><blockquote
cite="mid:CAAF6GDcEa_-pvD03cJz4PdJ=oTA_Tr2T6wAKiteTNZJ2R8PLyg@mail.gmail.com"
type="cite"><div dir="ltr"><div class="gmail_extra"><div
class="gmail_quote">
<div>... If I use RRL, my user queries can be degraded. And that is user
visible, including to stubs, even with caching. If you cause a caching
resolver to delay or timeout lookups that does hold up and impact stubs.
<br></div></div></div></div></blockquote><br>i any delay at all is to
you "user visible" even though once cached the same delay won't reoccur
within a DNS TTL interval, then so be it. DNS RRL is a DNS-specific rate
limiter which relies on retries, TC=1 behaviour, and caching -- by
design, mind you -- for its success. i'm not merely splitting hairs here
-- in my own testing, the only way i could cause a stub lookup failure,
noting that a stub tries multiple recursive servers and will retry to
each, was to send enough attack traffic toward all of that stub's
recursives to also cause failures on unrelated names. in that latter
case, it made no difference whether RRL was off or on, because the
attack was on the recursive name server's resources, not the RRL logic.
so, if you know a way to reliably cause targeted stub query failures
using an attack that only works with RRL turned on, i'd like to see your
demonstration.<br><br>vixie<br><br></div></body></html>