[dns-operations] rate-limiting state

[Paul Vixie]

Colm MacCárthaigh wrote:
> On Thu, Feb 6, 2014 at 3:28 PM, Paul Vixie <paul at redbarn.org
> <mailto:paul at redbarn.org>> wrote:
>
>     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.
>
>
> 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.

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.

>     so, third, let's look squarely at "large enough UDP flow to
>     activate RRL". 
>
>
> 10M requests/sec for www.example.com <http://www.example.com>, type=A.
> Would that be large enough?

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.

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

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.

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

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.

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

that is a complete (end to end, top to bottom) nonsequitur.

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

no. you've said approximately nothing worth calling out here.

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