<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:CAAF6GDf3wRKZZMz-dcPXZ37BfD+D71votMEjPOpQ=a2LfFcb0g@mail.gmail.com"
type="cite"><div dir="ltr"><br><div class="gmail_extra"><div
class="gmail_quote">On Thu, Feb 6, 2014 at 2:37 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>
<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"><div class=""><blockquote
type="cite"><div dir="ltr"><div><span
style="color:rgb(51,51,51);font-family:Verdana,Arial,sans-serif;font-size:12px;line-height:15.807999610900879px">For
example, if the authoritative provider <a moz-do-not-send="true"
href="http://www.example.com" target="_blank">www.example.com</a> were
to implement RRL
as you describe, then an attacker could spoof traffic purporting to be
from Google Public DNS, OpenDNS, Comcast ... etc, and cause <a
moz-do-not-send="true" href="http://www.example.com" target="_blank">www.example.com</a>
to be un-resolvable by users of those resolvers. <br></span></div></div></blockquote><br></div>no.
it just does not work that way.</div></div></blockquote><div><br></div><div>O.k.,
so say I spoof 10M UDP queries per second and 10M TCP SYNs per second
purporting to be from OpenDNS's IP address. Does RRL a) Let the
queries and SYNs go answered. Or b) Rate limit the responses? </div>
<div><br></div><div>If it's (a) RRL doesn't prevent the reflection. If
it's (b) then you complete a denial of service attack against the
OpenDNS users. </div><div><br></div><div>Which is it? or what's option
(c)? <br></div></div></div></div></blockquote><br>first, i think we need
smaller numbers, since at those volumes, opendns's pipes are full, and
nobody would get any answers to any questions. so let's pick some number
of requests and SYNs per second that is enough to use all the head room
opendns had, but without affecting response flows to queries not
related to your attack.<br><br>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. furthermore, RRL is not invoked for TCP-received
queries. whatever TCP sessions are able to start up are presumed to not
have a forged other-end. what you really want here is to use non-spoofed
TCP SYN so that you can camp onto all available connection control
blocks. if opendns follows RFC 1035, it won't close TCP sessions until
something like two minutes of idle time. you'd<br><br>so, third, let's
look squarely at "large enough UDP flow to activate RRL". when RRL is
active for a flow, it means the server is controlling its responses to
UDP questions which are from a certain netblock and which produce a
given response. by "control" i mean "don't just answer, think about it
first, consider your alternatives". one alternative is to drop the
question unanswered. another alternative is to answer with a truncated
UDP having TC=1. by default, netblocks are /24's and every third
prospective response is sent as a TC=1, and we will of course send
normal answers from time to time also. RRL's goal is attenuation, not
silence.<br><br>in your example, the forger is using a netblock that
contains opendns's upstream address, and it is soliciting responses
similar to the ones that opendns is trying to fetch. opendns only
fetches from authorities when it has a cache miss, so you have to find
something to spoof that opendns does not yet have in cache (or which has
a very low TTL).<br><br>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><br>my advice is,
don't take my word for it. build a VM farm inside your laptop, set up a
test environment, perform the experiment, and show us all the recipe
that results in maximum retries for a DNS stub. show the effort required
to deliberate create a service-affecting outage using RRL. i think
you'll find this an unsatisfying exercise but i am ready to study your
results.<br><br>so, (c).<br><br>vixie<br></div></body></html>