[DNSOP] Fwd: Comments on draft-ietf-dnsop-cookies

[Brian Dickson <[e-mail]>]

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