On Sun, 26 Jul 2015 22:56:10 -0700, Paul Vixie wrote: > > > >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.
I'm sorry, I feel like I'm stuck in "bring me a rock". There's been plenty of discussion about how one can safely deploy DNS-over-TCP (that is: security is not worse). That is not this thread. If you want to talk about transitioning UDP to TCP and sunsetting UDP, that's a new topic. That's not "secure it later". >>> 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? Great text. I missed it as the 8th of 10 references on the redbarn page, and not mentioned on the two AA pages. Mea cupla. >... -John Heidemann _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
