-DDOS: the current situation is that it is very very easy to construct a DNS packet and then the bandwidth requirement to defend DDOS continuely increases. the additional cost will be introduced in the "cookies" scheme, but it will be more flexible in this case because it will be very easy to diffentiate the packets-with-cookies and packets-without-cookies, and the cost will be much lower compared with the DNSSEC. in this point, "cookies" is a light-weight scheme compared with DNSSEC. -cache poison: DNSSEC is better to solve this problem compared with "cookies".
2015-08-03 Zhiwei Yan 发件人： Ted Lemon 发送时间： 2015-08-01 22:36:03 收件人： Paul Hoffman 抄送： 主题： Re: [DNSOP] Seeking more WG Last Call review fordraft-ietf-dnsop-cookies I sent this out on July 20, but unfortunately just to Paul Hoffman. I was puzzled as to why it didn’t get any response on the mailing list, but this explains it… :} On Jul 16, 2015, at 3:52 PM, Paul Hoffman <paul.hoff...@vpnc.org> wrote: > > <secretary-hat on> > > Greetings. The WG Last Call for draft-ietf-dnsop-cookies was supposed to end > today, but it got extremely little review during the Last Call. It would be > helpful to all of us if more people can review the document, say what they do > or don't like about it, and so on. I didn’t pay a lot of attention to this when it was being considered for adoption because it seemed notionally like a good idea, but I’ve now read the draft, and I’m rather confused. The document describes several attacks, and describes a mechanism for mitigating them. The method described seems as if it would function. However, I don’t see any way in which the proposed method actually mitigates the attacks that are described in the document. I also don’t see whether there are incentives for anybody to implement it. So I actually oppose publication of the document as a standard, because it’s going to wind up on some RFP checklist, and we’re going to have to implement it, but I don’t see how it’s actually going to help anyone. To expand a bit on this, the document describes two attacks that this method is intended to mitigate: DDoS and Cache poisoning. Let’s consider how the proposed mechanism would work for these. For DDoS, the cache or auth server is presumably going to decide whether to process a request based on whether the resolver on the client sent the right cookie. An attacker can’t receive the server cookie, so it can’t send it. This sounds great in theory, but now we have the server processing cookies in order to avoid processing something else. And this requires that all query sources support cookies; if they don’t, you don’t get any benefit, but you still get the cost. So is there some basis for thinking that we would see widespread support for DNS cookies on all resolvers? I find this unlikely. So we’ve actually created a new problem, rather than solving an old problem. For cache poisoning, who are we protecting? The document says that we are protecting the resolver, which could either mean the stub resolver on the client or the caching resolver. So I’m going to assume we mean the caching resolver. I suppose the theory here is that there is an incentive for auth servers to implement DNS cookies, and if they do we can avoid attacks, but again I’m not clear on how this is expected to work in practice. In practice we see that DNS server conformance by server providers is pretty abysmal. If it were the case that we had some way to know in advance that a particular auth server supported cookies, maybe that would work, but we don’t. So what we wind up with is that the caching resolver now needs to maintain a list of auth servers, mark whether these authors support cookies, and discard non-cookie responses to queries sent to those servers, in order to incentivize auth server operators to support cookies. Which sounds great until you consider that we now have a possible new DoS attack. It’s a little hard to implement, because you need to be on-path, but we’ve seen that being on-path isn’t really all that hard. So now I can intercept a query to a site I want to attack, respond with a cookie, and now that site is on the supports-cookie list. So if it doesn’t support cookies, the cookie-supporting cache will see a server failure, and now that domain is offline. So we have to do a lot of work, and I guess we get a little protection, but we have new risks. Whereas DNSSEC actually solves the problem. So if we are going to incentivize people to implement something, why not incentivize them to implement DNSSEC, rather than a very limited yet expensive half-measure? _______________________________________________ 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
