John Heidemann wrote: > ... > >> 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 :-)
that won't happen. or at any rate we should all we can to prevent it from happening. don't be alarmed-- what i mean is, until we have some idea what we'll do with parallel tcp sessions and what we'll do with concurrent udp transactions from the same initiator, we MUST NOT deploy, and we will therefore not garner any deployment experience. "build it first, secure it later" has not worked, ever, anywhere, for anybody. >> 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. really? i wrote ISC-TN-2012-1 (which is linked from the .../ratelimits page referenced above) and i thought this text was clear: 2.2.8. TC-RATE (2). When a query would be dropped due to rate limiting, we randomly send back a truncated response instead once per TC-RATE queries. This tells a victim whose address is being forged to retry using TCP. It's recommended that TC-RATE be set lower than LEAK-RATE. If TC-RATE is set to zero then this behaviour is disabled. and: 4.1. A victim whose IP address is forged in a large request flow should normally expect to experience unavoidable congestion on their Internet link. However, if all forged requests are sent to a small number of servers and if those servers implement rate limiting as described in this document then the victim will see a small amount of unsolicited response traffic and will at the same time have higher than normal UDP retry and truncation/TCP counts if they themselves ask the affected servers any question which solicits the same answer as is being solicited in the attack. what different words would you suggest, to better explain this concept? >>> ... >>> >>> 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. no, really. syn cookies help with TCB congestion even when spoofing is not used. > >>> ... >>> >>> 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". you make an excellent point. let me be correct this time: i think tcp's betterness vs. udp for dns only occurs in worst-case scenarios, but those scenarios are currently driving headlines, and are worth investing in. it is moderately saddening to me that we have to pay in best-case performance to get this worst-case benefit, and i would have preferred an RFC 6013 based approach (cookies all the time, tcp close is soft/temporary, and opportunistically save/reuse the prior window size on any subsequent session) but since Google TFO won that war, it's time to move on. -- Paul Vixie _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
