On Sat, 25 Jul 2015 19:24:17 -0700, Paul Vixie wrote: > > >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.
Hmmm, I was attempting to quote back exactly what you said. Clearly something failed. I concur that if you place the empahsis on the first three words that were quoted, then the statement is silly. I didn't mean it that way, and I assume you didn't originally mean it that way either. >> 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. I thought Shane made a thoughtful contribution: the observation that one can bulk-up a DNS-over-TCP with multiple requests, thus 7 TCP packets do the work of 40 UDP. That was a useful and accurate observation. My gripe is that going on to suggest that those 7 TCP packets are "easier" than the 40 UDP packets is incorrect for modern routers. In particular, characterizing Shane's scenario as "an attacker...[that can]...reliably deny service with a small number of small packets, which do not saturate any link" is incorrect. His TCP attack demands roughly the same number of bits as the UDP attack---counting packets here is misleading. >> 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. If you want to bring up some other TCP scenario, that's great. Let's not confuse it with what Shane proposed. > >> ... >> >> 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." The DNSOP WG discussion seems to be trending towards TCP with explicit signaling. BUT signaling seems quite off the point of Shane's thread, so perhaps that discussion is best had in a separate thread. >> 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. Glad to hear 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.) I don't think there has been discussion about that topic. Such a transition brings up a lot of issues. I have some ideas, but it seems premature to talk about handling UDP queries until we have significant deployment experience with DNS-over-TCP. I hope we will get there :-) > >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. Interesting. I didn't realize RRL included TC signaling to switch to DNS-over-TCP on DoS (I had read http://www.redbarn.org/dns/ratelimits, and BIND's AA-00994 and AA-01000, but only the BIND manual goes into the TC option in detail). That's a excellent use of both transport protocols. >> ... >> >> 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. It seems to me that that framing focuses on the payload. SYN cookies then prevent resource exhaustion (the number of TCBs on the server) that happens in the SYN-ACK exchange; the part that actually results in denial. Seems to me like it's six vs. a half-dozen. >> ... >> >> 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. I'm not sure how you reconcile "tcp is never better than udp" and "it has better worst-case performance". But it sounds like we have several points of agreement on TCP's potential role in handling DoS. And the poor 7-TCP-packet attack seems now thoroughly beaten to death. -John Heidemann > >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 >[email protected] >https://www.ietf.org/mailman/listinfo/dnsop > _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
