I'm a big fan of these cookies, and have been waiting eagerly for the draft to finally get picked up.
These comments are meant to be constructive, and with the goal of improving the draft quality and/or quality of the underlying protocol. And, of course, I speak only for myself. In no particular order: - Attacks/weaknesses of DNS protocol: I think it would be very helpful to add a subsection to either Section 2 or Section 3, concerning UDP fragmentation, and how currently all anti-spoofing protections (vs off-path attackers) are found in only the UDP header, DNS message header, and question section. Adding extra text concerning the EDSN(0) flexibility of OPT RR placement inside the Additional section, means it is probably also RECOMMENDED that the OPT RR (containing the DNS cookies) be placed at the end of the Additional section. This provides a much stronger defense against spoofing, by requiring the attacker to have the correct DNS cookies to poison a cache which implements cookies. - It may be worth including an analysis of the overhead of cookies in various states, and the comparative costs of cookies vs TCP. For instance, once the client and server have established mutual cookies, the cost of validating cookies becomes the cost of looking up a cookie via a hash table, and a cmp() operation. Keeping one old server cookie in addition to the current server cookie, would further reduce the overhead in cases where secret rollover has occurred. (If any value of BADCOOKIE other than the most recent server cookie is seen, IMHO it would be fair to discard the query silently, or do a minimum response WITHOUT a valid server cookie.) - It may also be worth pointing out that there is an additional benefit to clients in protecting themselves against arbitrary DDOS spoofing of authority server(s), by being able to white-list cookie-enabled authority servers, and to enforce the presence of cookies from those servers, and even to also statically add cookie values to the server white-lists (with fall-through logic for cookie mismatches, of course). Specifically, this attack vector appears to the victim as if it is an amplification attack, but in actuality bypasses the authority-as-amplifier, with packets sent directly from a bot-net to the victim, spoofing the authority servers' source address(es). - It may be worth explicitly making the distinction between black-listing IP addresses and filtering based on cookies. Both are effective at blocking DDOS traffic, but only cookies facilitate valid traffic flowing while attack traffic is blocked. Maybe something in an Appendix? Hope this is helpful. Brian Dickson
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
