[dns-operations] rate-limiting state

[Paul Vixie]

Colm MacCárthaigh wrote:
>
> On Thu, Feb 6, 2014 at 2:37 PM, Paul Vixie <paul at redbarn.org
> <mailto:paul at redbarn.org>> wrote:
>
>>     For example, if the authoritative provider www.example.com
>>     <http://www.example.com> 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 www.example.com
>>     <http://www.example.com> to be un-resolvable by users of those
>>     resolvers. 
>
>     no. it just does not work that way.
>
>
> 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? 
>
> 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. 
>
> Which is it? or what's option (c)?

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.

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

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.

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).

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.

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.

so, (c).

vixie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20140206/ef4aabff/attachment.html>