<html><head>
<meta content="text/html; charset=ISO-8859-1" 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:CAAF6GDfu5xMjFfFn35ETwDj2=7axnX1URi2cGf3Ceu9WtBHbhg@mail.gmail.com"
type="cite"><div dir="ltr">On Thu, Feb 6, 2014 at 3:28 PM, 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><div
class="gmail_extra"><div class="gmail_quote"><div><br></div><blockquote
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex"><div style="font-family:tt;font-size:11pt"
bgcolor="#FFFFFF" text="#000000"><div
style="font-size:11pt;font-family:tt">
second, RRL does not see SYNs. the kernel
probably has SYN flood protection, which like a stateful firewall might
penalize a host or netblock's real SYNs, but that has nothing to do
with RRL's logic.</div></div></blockquote><div><br></div><div>So the
reflection attack is completed? If you're going to respond to all of the
SYNs, you may as well respond to the UDP queries. It'll be the same
reflected PPS. The byte count will be a little higher, but most networks
are bottlenecked on PPS at DNS payload sizes. <br></div></div></div></div></blockquote><br>i'm
willing to discuss RRL's impact on third parties, since that' s our
topic here. if you are also worried about logic outside of RRL, please
start a new thread.<br><br><blockquote
cite="mid:CAAF6GDfu5xMjFfFn35ETwDj2=7axnX1URi2cGf3Ceu9WtBHbhg@mail.gmail.com"
type="cite"><div dir="ltr"><div class="gmail_extra"><div
class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex"><div style="font-family:tt;font-size:11pt"
bgcolor="#FFFFFF" text="#000000"><div
style="font-size:11pt;font-family:tt">
so, third, let's
look squarely at "large enough UDP flow to activate RRL". </div></div></blockquote><div><br></div><div>10M
requests/sec for <a moz-do-not-send="true"
href="http://www.example.com">www.example.com</a>, type=A. Would that be
large enough?<br></div></div></div></div></blockquote><br>it has to be
more than five or ten per second to trigger RRL, and less than a full
pipe to avoid being a non-specific DDoS. i can't say whether 10M
qualifies or not. let's say that there's 20MPPS in headroom, so that
your 10M example will not cause general congestion/exhaustion.<br><br><blockquote
cite="mid:CAAF6GDfu5xMjFfFn35ETwDj2=7axnX1URi2cGf3Ceu9WtBHbhg@mail.gmail.com"
type="cite"><div dir="ltr"><div class="gmail_extra"><div
class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div
style="font-family:tt;font-size:11pt" bgcolor="#FFFFFF" text="#000000"><div
style="font-size:11pt;font-family:tt">
in that steady state situation, opendns's
legitimate queries whose response matches an RRL flow are mixed with an
avalanche of forged questions soliciting the same answer. opendns will
retry three times over ten to 90 seconds. if opendns ever gets an
answer, it will fill its cache and stop asking that question. the
possibility of opendns receiving a TC=1 and retrying with TCP, or
receiving one of our periodic normal answers, and either way filling its
cache is high, on the order of unity. of course, opendns might ask
other authorities in between retries to any one authority, so you'll
need to spoof all of the potential authorities who could help with the
terminal cache-fill operation that ends the race.<br></div></div></blockquote><div><br></div><div>I
agree with all of this, but I don't think that the numbers work out. If
you're getting an attack of 10M PPS, which is very realistic, you'll
end up denying service to real users. <br></div></div></div></div></blockquote><br>are
you attempting to shift the onus of proof here? in my testing i have
not been able to create an attack against friendly traffic by triggering
the RRL logic on some victim's behalf. you assert that it's possible,
so, i'd like to see your demonstration.<br><br><blockquote
cite="mid:CAAF6GDfu5xMjFfFn35ETwDj2=7axnX1URi2cGf3Ceu9WtBHbhg@mail.gmail.com"
type="cite"><div dir="ltr"><div class="gmail_extra"><div
class="gmail_quote">
<div>Important to consider here, is that if you did nothing, and let the
responses go answered (if you can), there's no impact on the real
users.</div></div></div></div></blockquote><br>that was not my
experience. the unattenuated output flows toward forgery victims were
causing both network congestion and resource exhaustion that affected
untargeted third party "real users". that was the motivation for many
authority server operators to deploy RRL -- by which i mean, they were
happy to be stopping pain for victims, but even happier to make their
own pain stop. i think you may be speaking from ignorance here.<br><br><blockquote
cite="mid:CAAF6GDfu5xMjFfFn35ETwDj2=7axnX1URi2cGf3Ceu9WtBHbhg@mail.gmail.com"
type="cite"><div dir="ltr"><div class="gmail_extra"><div
class="gmail_quote"><div> The reflection target does get hit of course
though. So in effect, at realistic DDOS scales, RRL can be used to deny
service to your real users to protect victims of reflection attacks.</div></div></div></div></blockquote><br>that
is a complete (end to end, top to bottom) nonsequitur.<br><br><blockquote
cite="mid:CAAF6GDfu5xMjFfFn35ETwDj2=7axnX1URi2cGf3Ceu9WtBHbhg@mail.gmail.com"
type="cite"><div dir="ltr"><div class="gmail_extra"><div
class="gmail_quote"><div> That's a form of asymmetric altruism. I'm not
against it, doing the internet a favour is worthwhile, we all benefit ;
but it's worth calling out. <br></div></div></div></div></blockquote><br>no.
you've said approximately nothing worth calling out here.<br><br>vixie<br></div></body></html>