Re: [DNSOP] Seeking discussion of draft-ietf-dnsop-cookies-01
In message , =?UTF-8?B?56We5piO6YGU5ZOJ?= writes: > At Wed, 6 May 2015 18:33:24 +, > Evan Hunt 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
Re: [DNSOP] Seeking discussion of draft-ietf-dnsop-cookies-01
On Thu, May 07, 2015 at 09:11:53AM -0700, 神明達哉 wrote: > 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. Subject to rate limiting restraints, yes. BIND's experimental SIT implementation exempts clients from rate limiting if they have a valid cookie, but not otherwise. The cookie is more of a way for legitimate client traffic to be privileged, than for attack traffic to be mitigated; we have other mechanisms in place to handle mitigation. That said, however, I like the idea of adding the TC=1 response to the protocol specification as a MAY. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Seeking discussion of draft-ietf-dnsop-cookies-01
At Wed, 6 May 2015 18:33:24 +, Evan Hunt 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. 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
Re: [DNSOP] Seeking discussion of draft-ietf-dnsop-cookies-01
On Wed, May 06, 2015 at 11:19:07AM -0700, 神明達哉 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. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Seeking discussion of draft-ietf-dnsop-cookies-01
It appeared from me from the meeting in Dallas and the sparse list discussion is while the error codes would seem "interesting/useful", there is no good use case to show usefulness, which is my Mr. Andrews did not implement them. I was approaching this (and as we approach the idea of WGLC) that we drop the error codes for the time being since there is no working implementation; and there is no strong desire for them. I would rather lean in this direction, remove the error codes, and send the draft into WGLC as "Experimental". Does the working group have any strong opinions on this position? tim On 5/6/15 2:19 PM, 神明達哉 wrote: At Fri, 1 May 2015 23:21:30 +, Evan Hunt wrote: The chief difference between the two is the presence of an error code field in Eastlake cookies; Andrews found it redundant/unnecessary (as discussed in https://www.ietf.org/mail-archive/web/dnsop/current/msg13984.html). The hope was that including both mechanisms in the draft would lead to a working group discussion about whether the error code is, in fact, necessary or desirable; unfortunately, not much discussion has happened yet. 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. -- JINMEI, Tatuya ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Seeking discussion of draft-ietf-dnsop-cookies-01
At Fri, 1 May 2015 23:21:30 +, Evan Hunt wrote: > The chief difference between the two is the presence of an error code field > in Eastlake cookies; Andrews found it redundant/unnecessary (as discussed > in https://www.ietf.org/mail-archive/web/dnsop/current/msg13984.html). > The hope was that including both mechanisms in the draft would lead to > a working group discussion about whether the error code is, in fact, > necessary or desirable; unfortunately, not much discussion has happened > yet. 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. -- JINMEI, Tatuya ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Seeking discussion of draft-ietf-dnsop-cookies-01
Evan, On Friday, 2015-05-01 23:21:30 +, Evan Hunt wrote: > Speaking for myself, I agree with Mark: the benefits of including > error codes in the option are slim and other mechanisms such as > FORMERR work just as well in almost every scenario, so it doesn't > justify the cost in additional complexity. This makes sense to me. Best to tackle a single issue at a time. Although perhaps a next logical step would be to think about improving the error code situation in general. :) Cheers, -- Shane ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Seeking discussion of draft-ietf-dnsop-cookies-01
> On May 1, 2015, at 4:21 PM, Evan Hunt wrote: > > Speaking for myself, I agree with Mark: the benefits of including error > codes in the option are slim and other mechanisms such as FORMERR work > just as well in almost every scenario, so it doesn't justify the cost in > additional complexity. I'm inclined to agree. I was a bit torn because there have been so many other times I wished a certain feature had additional error signaling, but I found it hard to justify the complexity in this case. DW ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
