John Heidemann wrote: > On Sat, 18 Jul 2015 10:27:41 -0700, Paul Vixie wrote: > >>> ... With modern routers my understanding is it's usually bitrate not packet >>> count that is the limit. Bitrate is about the same for UDP vs. TCP. ... >> ... on the internet we have, packets per second are a common bottleneck, >> such that an attacker knows they can reliably deny service with a small >> number of small packets, which do not saturate any link, but which do >> saturate the kinds of routers and firewalls people actually do still buy and >> use today. > > I agree, we need to prevent "an attacker knows they can reliably deny service > with a small number of small packets, which do not saturate any link".
wait, we may not agree, since i don't see similarity between my statement and your restatement. it makes no difference in my view what an attacker knows. attack resources are cheap. like spam, ddos need not be targeted. for example, the 400Gbit/sec DDoS against spamhaus a few years ago was done with random destination addresses of spoofed-source queries, and enough of these random destinations provided an answer, to create operational problems for spamhaus' online presence. > But that is not *Shane's scenario*. other than clarifying what i thought shane meant, i plan to stay out of that scenario, since his proposed python script looked like it needed a non-spoofed source address, and so it demonstrates a different weakness than the ones i spend most of my time thinking about. > Shane's scenario was 7 FULL-LENGTH TCP packets vs. 40 SHORT UDP packets. > That is what I meant by "bitrate is about the same for UDP vs. TCP". > Shane's attack is not a shrew-style attack on TCP---he IS saturating the > link, just with aa few big packets instead of many short packets. well, if i read it correctly, the link being saturated actually participated in session setup, and so i'll leave you and him to follow that thread without me. > ... > > Agreed, we cannot upgrade other people's routers. > > But, I'm sorry, if you're running DNS on an old router, you're trivially > DoS-able today. Millions of insecure computers to tens of Mb/s uplinks. It > only takes a couple to saturate a link, either in packets or bits. from a protocol evolution standpoint, our burden is to not make things worse for someone who has a working configuration today. so when i consider old routers, i don't wonder if they can't be targeted today, only whether they will be more naturally targeted by a prospective change to the protocol. so for example, i argued extensively against "just use tcp as the primary transport for dns" because without some kind of new signaling, this would create resource exhaustion attacks against servers who strictly and/or simplistically implement the DNS standard's tcp connection management. whereas, if tcp can be negotiated without creating such an attack vector, i have no objections. what i hope this demonstrates is that i think explicitly-consenting protocol agents should work together however they want, but that consent cannot be seen as implied. in that same way and for similar reasons, we should design around the assumption that most of the weak far-side routers will not be upgraded in our lifetimes, and we should both subtract out any current method of packet-bombing them with spoofed-source requests, and also not add any new method of such packet-bombing. we should never say "since they're weak, they're already vulnerable, and so we don't have to worry about making their situation worse." > > My second point was (2) TCP allows a path to MUCH better. > > Your reply elided that part of my post, which was: > >>> Liang Zhu did some testbed experiments of DNS under UDP and TCP >>> attacks---we found that DNS/TCP can be quite a bit more robust to DoS >>> than UDP when one takes basic defenses like the HTTP people do (that is: >>> rate-limit queries per connection, connections per IP, and use SYN >>> cookies). i don't think anybody has argued against what can be proved in a lab, and few of us here have argued against what could be built using a new port number. zhu's work shows a system having better worst-case performance, and worse best-case performance, than the current dns system. and as long as any change to the when-to-use-tcp-and-for-how-long predicate is explicitly negotiated with the default being to assume that the other end wants the old behaviour, i think those tradeoffs (better worst-case, worse best-case) are reasonable. so, i didn't include that part of your post, since i wasn't disagreeing with it. since you brought it up, i do want to know what the udp response policy will be for servers who have a new-style (explicitly negotiated) persistent tcp session in place. ideally, there will be some capability for multiple tcp sessions between the same endpoints (like the web does on tcp/80) and also some capability to simply ignore udp queries from currently-connected-far-ends (since these may be spoofed, and we'd like the existence of a tcp session to protect against that vector.) the rest of this is even more off-topic and inside-baseball, but not (in my view) irrelevant or uninteresting: > ... > > With UDP and spoofed source addresses, each attacker gets to hit you with > their full line rate, AND you have to service all the queries. This exhausts > your incoming bitrate, packet rate, or CPU speed depending on how you're > configured. with RRL we showed that it's not necessary to service all of the queries. a careful drop policy along with a careful TC-signaled TCP transport switch can result in successful cache fills such that the far-end application gets good service even when the vast majority of the attack volume is dropped. this is a minor matter but i'd like the record to be clear. > ... > > With TCP, you get a whole bunch of defenses: > > - Spoofing is prevented with SYN cookies, so a spoofing attacker never gets > to hit you with Shane's full length packets in the first place. The spoofed > IPs are stopped at the SYN with NO state on the defender's server. SYN cookies are a solution to a different problem (TCB overrun attacks). what stops spoofing when TCP is used is the random initial sequence number of the SYN-ACK. again, a small matter. > ... > > This data supports the the claim that TCP can be "better". I still don't see > a complete "sometimes worse" argument. i think tcp is never better than udp, but that doesn't matter, since it has better worst-case performance, and udp's worst-case performance includes spoofed-source attacks, which are hard to live with. it's possible that shane didn't understand that he was comparing a tcp-based attack (where spoofing can't work) against udp-based attacks (where it can.) there are a lot of moving parts in this thread, and a lot of timezone traversals by its participants. -- Paul Vixie _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
