[dns-operations] rate-limiting state

[Colm MacCárthaigh]

On Thu, Feb 6, 2014 at 4:06 PM, Patrick W. Gilmore <patrick at ianai.net>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.
>
> Paul was responding at RRL. Whether the OS on a name server responds to
> SYNs is outside RRL's scope.
>

I don't think it is, if the point is to reduce the impact of reflection
attacks then we need to consider every source of reflection. Per Paul's
article he calls out TCP and ICMP as reflection friendly.

Plus who is going to hit a name server with SYNs when pretty much every
> server on the Internet will ACK any SYN sent to it? Pick your favorite NN
> million servers and send them all 10 SYNs / sec, will fall under anyone's
> rate limiting and you're done.
>

Amplification is one reason that people use DNS servers as reflectors, but
another common one is that they are hard to filter. If www.example.com is a
well-known site, then the target may need to permit traffic inbound from
their nameservers. You as the reflection victim can't simply filter it;
there'll be impact. I think that's why even non-amplifying reflection
attacks happen that way.

> 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.
>
> You don't think the numbers work out? That's your response. Lots of people
> have RRL installed & have survived attacks with it. Have you any data other
> than "I don't think that the numbers work out" to show otherwise?
>

I don't see anyone disputing my example, and I'm not calling out RRLs
ability to dampen a reflection attack. I'm saying that RRL can be used to
counter-attack your users.  Let's say a busy website gets 1,000 QPS of
"real" user queries. If I want those queries to survive say with 2 retries,
then I need to let through 40% of traffic to have a 95p confidence of them
getting an answer. Yes, I'll have mitigated the reflection to 4Gbit/sec,
but meanwhile users will be seeing increased resolution times and timeouts.

> 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.
> 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'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.
>
> I think you'll find there is huge impact on the real users, since the
> target is down and the target is a real user. Plus all the people between
> the reflector and the target.
>

Not necessarily; large targets often come with a lot of defenses and don't
always need help from the reflectors. There's a large class of targets that
are unprepared and may be impacted, but it's a complicated trade-off. I
think with RRL you have to consider whether you value defending the third
party target (who you may or may not have any relationship with) or or
value your users?  There are ways to do both, with more sophisticated
spoofing and reflection attack detection.

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