<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Feb 6, 2014 at 4:06 PM, Patrick W. Gilmore <span dir="ltr"><<a href="mailto:patrick@ianai.net" target="_blank">patrick@ianai.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">>> 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.<br>
</div><div class="">
><br>
> 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>

<br>
</div>Paul was responding at RRL. Whether the OS on a name server responds to SYNs is outside RRL's scope.<br></blockquote><div><br></div><div>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. </div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote><div><br></div><div>Amplification is one reason that people use DNS servers as reflectors, but another common one is that they are hard to filter. If <a href="http://www.example.com">www.example.com</a> 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.<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">> 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>

<br>
</div>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?<br>
</blockquote><div><br></div><div>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. </div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
> 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.<br>

<br>
</div>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.<br></blockquote><div><br></div><div>
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. </div>
</div><div><br></div>-- <br>Colm
</div></div>