On Aug 4, 2015, at 11:36 PM, Mark Andrews <ma...@isc.org> wrote: >> Actually we can make a lot of predictions. First, if there is no >> incentive to implement it, vendors won’t implement it, so we can safely >> assume that adoption on stub resolvers will be very slow. > > Well there are multiple vendors who have stated they intend to implement.
Who? >> It’s possible >> that this could go a different way, but if history is our guide it won’t. >> There is a huge incentive for DDoS attackers to come up with ways to >> bypass and leverage it, though. Let’s think through some cases (I’m >> going to channel the following analysis from a private exchange I had >> with someone at Nominum who has a lot more DNS fu than I do, so if it >> seems brilliant, he gets the credit, and if it seems stupid, it’s >> probably because I am a lousy medium): >> >> Client good, no cookie: client treated normally, rate limited for >> excessive traffic (client may be broken but not malicious, still needs >> rate limit). >> >> Client evil, no cookie: client treated normally, rate limited for >> excessive traffic because malicious. >> >> Client good, has cookie: client treated normally, rate limited for >> excessive traffic because might be broken. You can treat clients that >> have cookie preferentially, but you still have to rate limit them since >> they may be broken. >> >> Client evil, has cookie: client treated normally, rate limited for >> excessive traffic because evil. If you treat good clients >> preferentially, you’re also treating evil clients preferentially. > > The analysis above is lacking. > > "has cookie" is not the determining factor. "has good server cookie" > is the determining factor. That’s what “has cookie” means. > Now without cookies you can't determine the difference between 1 > and 2. With cookie you can determine the difference between 3 and > 4. Additionally how you treat 1 and 2 is different to how you tread > 3 and 4. How can you tell the difference between an evil client and a good client based on the cookie? >> You may be tempted to say “but the client is a DDoS client, so it won’t >> have a cookie.” This is false, because the client may be an open >> resolver that implements cookies, and indeed open resolvers that >> implement cookies will now be specially favored as attack vectors. And >> of course botnet attackers have legit IP addresses and use them, so again >> they can and definitely will implement cookies. Worse, they can now >> make you do more work in order to rate limit them, because they can make >> up new cookies. And if you rate limit by IP address as well as cookie, >> then you are doing the same amount of work as if you just rate limited, >> so cookies provide no benefit. > > No so. With cookies you by IP address no cookie, IP address bad/no > server cookie, IP address (or by client cookie) good server cookie. I’m sorry, but I can’t parse that. Can you restate it? > The attack traffic falls into bins 1 or 2. Legitimate repeat cookie > client traffic falls into bin 3. Now most legitimate clients are > not broken so the chance of them being rate limited is low. Clients > which don't implement cookies take all the negative consequences > of being binned with attack traffic. I don’t see any mention of bins 1, 2 and 3 in the draft. Can you explain what you mean? > >> All of this goes for other potential sources of attack, like states and >> weak jurisdictions. >> >> The recursive->auth path is easy to attack with two-way communication, so >> cookies don’t really help you here unless you also do per-source rate >> limiting, at which point cookies also don’t help you because they add no >> value if you are doing per-source rate limiting. >> >> (Back to me…) This doesn’t even get into the attacks you can do against >> a server that has the stateless implementation proposed in the draft. >> In an implementation that does no per-source rate limiting, a botnet or >> open-resolver network that can do cookies can now shut out the vast >> majority of legitimate clients that do not do cookies. > > Hogwash. Where does anyone say not to service non cookie traffic. You > are making this up in you head. If you are preferentially responding to cookie traffic, then if you are being DDoS’d by someone who has implemented cookies, every single non-cookie client is going to get swamped. Some may get their queries answered, but most won’t. If you are not preferentially responding based on cookies, then what’s the point of using cookies? Also, could you please not use pejorative terms like “hogwash”? If you disagree with me, all you need to do is point out my error. > Actually there are good reasons for clients to implement cookies. > They reduce the amount of port randomisation that needs to happen > in a recursive server (if the server supports cookies you don't > need to randomise the source port) and client cookies work even > when the NATs undoes port randomisation. The isn’t mentioned in the draft. > Even when the client does DNSSEC validation this is useful as the > referral is not signed. If you mean that the packet containing the referral is not signed, and that only the data it contains is signed or not signed, then I agree. The problem is that this isn’t an argument in favor of cookies: if cookie work, then you don’t need this argument, and if, as I am claiming, cookies are harmful, then the fact that they happen to help you in this case isn’t much good. Cookies can definitely help to prevent spoofing in the case of an off-path attack like Dan’s, but the damage they do is far worse than the benefit they offer. I think if cookies were used just for this one case, it would be a lot easier to justify them, but this doesn’t seem to be the primary motivation for using them, and the DDoS case, plus the fact that they aid massively in on-path attacks, is a real problem. Unfortunately I don’t see a way to mitigate the on-path attack other than DNSSEC. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
