On , Zhiwei Yan wrote:
-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.
Depends on what the definition of DoS attack is. only the client side mechanism (can be anything, either cookie or simplest one) can mitigate DoS attack on client. But the server side, IMO, cannot do much help as far as they explained in the draft.
in very special scenario, what it can do is only convert DNS amplification attack to DNS reflection attack which is again a kind of DoS attack on client. If the client implemented DNS client mechanism (whatever, it can be or only by keeping the track of its communication to server or we say e.g. client cookie where this cookie is only kept in client and not sent to server) then either it is DNS amplification attack or reflection attack, the client machine behaves the same way and drops all messages that it haven't requested. So, implementation of server side doesn't change this.
Because, the server does not create the same cookie for client since the server secret might be different for new request. Therefore, server_cookie1<>server_cookie2 that is generated for the same IP address and might be also with the same client cookie. Therefore there is no authentication in server side. If we also assume that server keeps the IP address of the client and its binding to cookies for a short time in server's memory, it is the same as when server only keeps the IP address of client and does not accept any further request that comes immediately from the same IP address or does not accept more than 2 or 3 request per seconds. So either server go to generates cookie or not, by only keeping the IP address and give it a time limit, can transfer DNS amplification attack to reflection attack that in both cases, as I explained before, client behave it the same way(as Alice either eats all the cookies or say she has on diet and drop them :-) )
Furthermore, the usefulness of the server side part of that is conditional. This means the adversary also cannot sniff his own messages sent to a DNS server so that it also includes server cookie generated as an answer to the adversary's cookie with fake source iP address.
This is really a strong assumption that in reality the situation is 50/50 or less. So, the question is that does it worth to consider the "Server-side" of this mechanism as it is defined in the draft by considering the fact that it MIGHT only convert the DoS amplification attack to reflection attack that is again a kind of DoS attack on client? Please note that the networks are not without any protection as the assumption of this draft is. In the network there are IPS, IDS and firewalls where mitigates such attacks on the networks. So, if adversary based on Alice IP in her email, started using that for attacking her, if Alice's IP belongs to enterprise, they did not left their network open to DoS attacks and let the adversary to target Alice that is inside this network.
Therefore, the next question is what is the purpose of the attacker to attack Alice who found her IP address by chance from the email and why should the adversary put efforts to do this? Who is this client that this mechanism wants to protect?
The new version of the draft also didn't address these questions or couldn't answer the previous concerns about their mechanisms.
Best, Hosnieh _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
