Re: [DNSOP] Summary of the two options in draft-ietf-dnsop-cookies?
In message <20150330030443.ga23...@isc.org>, Evan Hunt writes: > On Sun, Mar 29, 2015 at 06:38:24PM -0400, Donald Eastlake wrote: > > The big argument against a Cookie error field, that I can see, is that > > it isn't there in the BIND implementation and running code speaks > > loudly in the IETF. > > When this is standardized, BIND will be changing the OPT code anyway; > modifying the option format wouldn't be a huge problem. (I suspect it'll > be more of an annoyance to change the name from "SIT" to "COOKIE".) > > Would it be reasonable to leave space in the option for error reporting, > but leave it up to the implementor to decide whether to bother doing so? Whether you generate the error code or not is immaterial. If it is there then the client has to code for it. > -- > Evan Hunt -- e...@isc.org > Internet Systems Consortium, Inc. > > ___ > 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
Re: [DNSOP] Summary of the two options in draft-ietf-dnsop-cookies?
On Sun, Mar 29, 2015 at 06:38:24PM -0400, Donald Eastlake wrote: > The big argument against a Cookie error field, that I can see, is that > it isn't there in the BIND implementation and running code speaks > loudly in the IETF. When this is standardized, BIND will be changing the OPT code anyway; modifying the option format wouldn't be a huge problem. (I suspect it'll be more of an annoyance to change the name from "SIT" to "COOKIE".) Would it be reasonable to leave space in the option for error reporting, but leave it up to the implementor to decide whether to bother doing so? -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Summary of the two options in draft-ietf-dnsop-cookies?
Hi, I've made some progress on the FNV code. I expect to be able to advance it, presumably as AD sponsored, before the next IETF. On DNS Cookies errors, I agree that the utility of the error field, as far as we can see right now, is quite limited. Still, there can be error conditions in the Cookies in queries when the server decides to go ahead and provide a normal full response, so it seems to me desirable to provide a way to return an error code inside the Cookie OPT Option without disturbing the top level RCODE error field. An error is traditional for some "security" enhancements to DNS. See, for example, the error fields in TKEY and TSIG. The big argument against a Cookie error field, that I can see, is that it isn't there in the BIND implementation and running code speaks loudly in the IETF. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Sun, Mar 29, 2015 at 1:30 PM, Paul Hoffman wrote: > 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. > > 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Summary of the two options in draft-ietf-dnsop-cookies?
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
[DNSOP] Summary of the two options in draft-ietf-dnsop-cookies?
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. 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
