In message <caje_bqc0unc6dtsjls8oeeka2mexxphbgijqaxfn7_awvq_...@mail.gmail.com> , =?UTF-8?B?56We5piO6YGU5ZOJ?= writes: > At Wed, 6 May 2015 18:33:24 +0000, > Evan Hunt <e...@isc.org> wrote: > > > > Can someone explain why we'd need the separate error codes based on > > > the position of supporting them (i.e, not to persuade others on > > > dropping them)? msg13984.html was basically written to argue against > > > them, so it could potentially and unintentionally be biased. I'll try > > > to find any such explanation myself, but if someone already knows it > > > better can do that, it would also help. > > > > "Next by thread" from msg13984 has Donald explaining his position, > > though not in great detail. If I understand him correctly, he wants to > > enable a server to include cookie errors even if it's chosen in this > > case to return an otherwise normal NOERROR response to the client. > > Okay, so it seems to be a case where the YAGNI principle can apply. > > On the other hand, on reading the draft and > https://www.ietf.org/mail-archive/web/dnsop/current/msg13984.html > more closely, I can see some not-so-trivial difference. Assume DNS > cookies are deployed sufficiently and some operators start refusing > queries without cookies. Then an attacker that wants to spoof a > victim client (probably for an amplification attack) would send > queries with an invalid server cookie anyway. According to Section > 7.2.4.1 of draft-ietf-dnsop-cookies-01, the server will still return > the full size of response, so the attack will still be effective. On > the other hand, a server implementation with the separate error code > field can choose to send a minimal response with a valid server cookie > according to Section 5.2.3 of the draft, thereby minimizing the risk > of allowing amplification attacks while still allowing legitimate > clients to bootstrap or re-synchronize. > > In the following part of msg13984.html: > > >> For (b) retrying should succeed. That said tc=1 would also be just as > >> effective at triggering a retry. > > perhaps Mark tried to say we could achieve the same effect if the > server returns a minimal size of response with TC bit on and with the > correct server cookie. If it was his intent, it's true to some > extent. But these two approaches are not entirely the same since > using the TC bit has a side effect of forcing the use of TCP.
Which gets the client/server what is needed for this and future transaction. It avoids the two denial of service senarios below. Just sending back BADCOOKIE leads to a potential denial of service with misconfigured anycast servers with differing shared secrets / server cookie algorithms. Just sending back NEEDCOOKIE leads to a potential denial of service when DNS COOKIE is not understood. Additionally a server can choose to send a minimal response rather than a full response or TC=1. In both cases it is a unverified query source and should be handled like all unverified query sources. I also have a hard time envisioning a client that supports DNS COOKIES not sending a DNS COOKIE by the time one could reliably send back NEEDCOOKIE and have it reliably acted on. The only reason for not sending a DNS COOKIE in the first place would be to handle broken EDNS servers and that is a solvable problem if everyone that depend on the DNS for their pay cheque does their bit to fix it. At the moment sending back NEEDCOOKIE would be equivalent to REFUSED and I don't see the equivalence changing. > So the choice does not seem to be a no-brainer to me. But, in the > end, I wouldn't be opposed to the idea of removing the separate error > code field. The above difference wouldn't be so substantial anyway, > and wouldn't justify the introduction of a generic error code field. > > One last point I'd like to make is that, assuming the above > understanding of mine is correct, I'd suggest including the TC bit > hack in the initial protocol description. Since it has a side effect > it's better to have it sooner so we can update the spec if early > deployments suggest the need for it. > > -- > JINMEI, Tatuya > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
