> > This is not highlighted in the draft which makes it confusing for the > > reader which causes to raise such question regarding NAT. > > Because it is irrelevent has to how the attacker chooses the address to attack. > What is relevent is the impact the attack is happening and how a server can > sort some/all legitimate traffic from the client out of the which is being > spoofed.
But this is confusing. Because the document somehow highlighted the fact that the attacker has no possibility to sniff the communication between the DNS server and client and then the document starts talking about attack and assume that the attacker knows the IP address of the node that is behind NAT. So this raises the questions. Even one sentence explaining that the attacker knows this IP address from previous traffic between these nodes would be helpful. > > > > > Having middle boxes modify packets is a *bad* *idea*. > > > > > > > > Might be, but this is also not applicable. > > > > > > But you just suggested that the NAT box do that. > > > > Because I did not know how the attacker would target a single node > > behind the NAT without knowing the IP address (please refer to my last > sentence). > > Therefore, I saw the target as a whole network or the NAT device. > > Whether it is the client or the NAT it doesn't matter. They are one and the > same as far as the world is concerned. But all the document highlighted NAT scenario. If it is applicable to other scenarios, then it needs to be mentioned in the document. By reviewing the document, I had this impression that this mechanism is only for the case where a client is behind the NAT and all what this mechanism is do is to somehow protect this client. Which was the result of so many discussion over the NAT and client Ip address that is not seen behind the NAT. > > The client keeps state: the client cookie it sent and the server cookie > returned. > > * If it is a recursive server this state is keep with things like the DNS PMTU of > the server or if it supports EDNS. I skimmed RFC 6891 which is the base of this work. IMO what you say here seems to be in contradiction with that RFC. See section 6-2 of that RFC. Since cookies are a kind of OPT RR, "they MUST NOT be cached" And now you're talking about combining this mechanism with DNS EDNS (which is OPT RR) which help server to recognize the client?! Sorry I am not convinced with the mechanism in the draft. I have tried to explain my reasons. I am convinced about having some client side only mechanism and not as complicated as producing cookies but it can be anything to keep the state of queries sent to the DNS server. But not convinced of server side mechanisms to the extend it is explained in the draft. Just to summarize what seems to add value and what seems not add necessarily any additional value to the existing systems, I explain everything under two subtitle: advantages and disadvantages: Advantages: - Good to have a client side mechanism which keep state of its own query and discard anyone that it doesn't have any state about. So client_cookie to some extend address this requirement but the problem could be address much easier. In other word, this doesn't need necessarily that the client do any special process to produce cookies. It can be simply by keeping even a sequence number regarding the query it submitted to DNS server or a bit regarding to the query. For example if it sends a query to DNS server and waiting for the response, then the bit is set to false and if it received the response, the bit is 1. In that case if it receives any DoS attacks (a large number of queries), the client only checks the bit. When it doesn't expect any response, without processing the large queries, discard them all. And ok, for your case that is different and you go through the process of producing cookie. That is also ok but needs more processing time than simply assign a bit for each real query and only dependent on the client without thinking whether or not the server support this approach. Disadvantages: - Not good to have server side part of this mechanism - If one look at the client cookie and server cookie, there are only some numbers (ok ok.. they are produced by xx algorithm but actually they are unrelated numbers.) in other word, the server might not produce the SAME cookie for the same client because the "server_secret" is different everytime. So, the server cannot identify the same client by only calculating the cookie based on the client IP, client cookie and its own secret. This allows an attacker to still submits query to server with spoof source IP address of the victim client. So, for server [1] What needs the server to keep to make the proposal valuable is that the server keeps the mapping of server_secret for each client. Therefore, Even with the solution [1], once the attacker submits a query to the server with spoofed source IP address and has the possibility to eavesdrop the query response (that he himself originated it with the spoof IP), then he get to learn server_cookie for this specific client and include it to every single request it submits to server. So at the end, maybe once it worked , with considering the fact to keep the mapping on the server (which is not in the draft and the base of this draft is different) - RRLs seems to already work to some extend for servers. So, I am not sure what additional value it adds (my comment is only the server_cookie or server side mechanism of this draft) [2] server might want to use different server_secret even for the same client to address the problem of [1]. But unfortunately, the server cannot calculate the same server_cookie for the same client. therefore, this gives an attacker a big chance to apply its attack as for the result of [4] [5] is different for the server. So if the server uses RRL, then either the server uses this mechanism or not, it doesn't help the server nor the client to authenticate eachother. [4] Query 1: server_cookie =Pseudo_function (client_cookie + 192.168.1.1 + 789999) where server_secret = 789999 ---> server_cookie=a74t54545 [5] Query 2: server_cookie =Pseudo_function (client_cookie + 192.168.1.1 + 877766) where server_secret = 877766 ----> server_cookie = b9977005 So both [4] and [5] was for the same client but server result cookie is different. [6] By considering all the above fact, the solution now is keeping the mapping of client_cookie as well as server_secret in the server so that the server can differentiate this client from other clients and also the attacker. [6] would work as long as the attacker doesn't get to learn the client_cookie, if it learns it then it only copy it to each of its request and for server it is similar to the client. So it is like the server doesn't know how Alice is look like and alice supposed to receive an important letter, the attacker can also go to server and say I am Alice. Server asks for Alice's cookie, but attacker also copy Alice cookie and has it. therefore, from the server, the attacker is identified as Alice and could forge the identity of Alice. Alice used cookie but didn't help it. Last but not least, since in the draft server_secret is not kept in the server and there is no client actual authentication as explained in [6], then the server side mechanism does not help the client. So, again back to the problem of such database that needs to keep this mapping and search over each records for the server. This depends on also the number of clients that query this server. So if you consider a public DNS... ... > * If it is a stub resolver it could be kept in a shared memory segment that all of > the stub resolvers instances can access or a well known file or there could be > a lightweight daemon than just remembers cookies. In all cases appropriate > r/w locking needs to be done. How it is kept is not important. Alternatively > the stub could establish its own cookie pair by sending a QCOUNT=0 query > with only a client cookie then send the query it want the answer to. I think there is misunderstanding. My concern is not why we keep the state in client. my concern is that the server side part of this mechanism doesn't work and not helpful. > > It can attempt a amplification attack. As I stated earlier and in the document > this is used in conjuction with other things like resource rate limiting. I don't see any additional value that this draft can bring to the existing mechanism by including the server side part of the mechanism. Client only is good and can work with RRLs and other mechanism. > See the logic above for how it helped the client. It got a answer rather than > having the query dropped. With RRL as you discussed about, it can also receive an answer. If the client doesn't try to send a lot of messages to server in a short period of time. It is of course the bad luck of client if the same time as the attacker starts attack, it also starts requesting any query from the DNS server. In that case, it doesn't matter whether we have this mechanism, based on the rate, the server, might also drop the client's request. Best, Hosnieh _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
