In message <683e2720-66f7-4b45-8787-99bd93fa2...@vpnc.org>, Paul Hoffman writes : > Greetings again. Can one of you summarize the differences between > sections 4/5 and 6/7 in the recent -01 draft? It seems that the error > code processing in 4/5 might either be useful or overkill.
I can't think of a good use for the error codes which is why I didn't add them to SIT. They are in -01 so the group has the two formats written down for evaluation. BADCOOKIE The senarios I can see that would result in this being sent are: a) The server is under attack b) The client has a old cookie c) Mismatched cookie generation between a anycast instances and the client can retry with the cookie from the response or stop sending cookies. A legitimate client doesn't see the (a) responses. For (b) retrying should succeed. That said tc=1 would also be just as effective at triggering a retry. For (c) you are likely to get dueling servers and not progress to giving the client a valid response. The client will have to maintain a BADCOOKIE response counter and then fallback to not sending a COOKIE. MFCOOKIE The senarios I can see that would result in this being sent are: a) The server is under attack b) The client is badly coded This should really be a FORMERR if the option length is invalid. NOCOOKIE This is just a more precise REFUSED and needs to be a rcode if we need this level of precision. Spontaneously adding a cookie opt to a reply without one doesn't help clients that don't understand cookies. Additionally it will be decades before anyone could set this on the Internet. > A related question for Don: how close are you to getting > draft-eastlake-fnv published? For me, it is mandatory for that draft to > be stable (and hopefully published) before we publish > draft-ietf-dnsop-cookies in order to make developers comfortable in > deploying cookies without possibly opening servers and clients to CPU DoS > attacks. > > --Paul Hoffman -- 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
