Mark, Thanks for your explanation. My comments are inline...
> -----Original Message----- > From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Mark Andrews > > If the victim node is behind NAT (servers are not behind NAT), and > > attacker is not in the same network, IMO, it cannot perform any > > amplification or DoS attack on the victim node. unless otherwise, the > > attacker is aware of the communication and ports used for the clients > > behind the NAT. Therefore, the use of this mechanism is not applicable > > in such situation. Therefore, I do not see any use case for nodes behind > NAT. > > It can DoS the path to the NAT. All the attacker needs is the public address of > the NAT. For the DoS stream to go through the NAT assuming it is a stateful > NAT then yes the attacker needs more knowledge. So, you want such mechanism is implemented in NAT devices to protect all clients in that network, right? If not, the implementation of that in a single client behind the NAT, doesn't help all the clients inside that NAT network because the target is a public address of this device and other devices are not seen. This is , of course, according to your argument. Because if the attacker is using the public address of the NAT device then it is the NAT device who is the target of DoS. Then, if the mechanism wants to be applicable, then NAT device is the device which needs to implement this mechanism and not each client and add this option to any packet passes it that targets a recursive DNS server or store the state of server cookie. > > If the client has a global IP address, for example if it uses IPv6 > > that usually the IP address is global, then the attacker has a > > possibility to perform the DoS attack even though the client uses this > method. because: > > > > - As far as I understood from the method, It is similar to enclosed > > figures (the algorithm is only arbitrary algorithm but this really does not > matter). > > The problem is that still amplification and spoofing or any attacks > > explained in the draft is possible The reasons are as follows: > > > > 1- client doesn't know the random number used by the server to > > calculate the servers' cookie response. if it needs to know then it > > returns to the barrier of sharing this value between clients and > > servers > > The client sends queries only with client cookies initially. These are treated > like any other unauthenticated query. They are subject to rate limiting of > responses and sending back minimal responses (rcode=BADCOOKIE or TC=1). If the server doesn't keep the state, then based on the algorithms explained in the draft, the server cannot differentiate between different clients and each time it might generate a new server_cookie for each requests (I had it in my previous message on the figure attached to the message) because: [1] Server_cookie=Pseudo_function(client_cookie + server_secret) Therefore, even though, the client stores state about the server_cookie, each time for each query request, server will give it back a new cookie that clients cannot compare and calculate it and it is like a completely new query. Furthermore, if we assume that the algorithm is like the following, so that the server produces, everytime, the same cookie for the client and if the assumption is that the client knows the IP address of the server, then the attacker still has the possibility to spoof the source IP of DNS server because there is no actual server authentication and no one can proof that the message comes from the legitimate DNS server. [2] Server_cookie=Pseudo_function(client_cookie) So, in [2] the attacker once ask for a query from this DNS server, it can get to know how DNS server calculates the cookie and since it is not changeable over the time, the attacker can spoof the DNS server. In other word, training phase in not useful in both scenario and keeping state on client doesn't also help to mitigate the attack. > > 2- The server has no way to authenticate the client. so, it also > > accepts any arbitrary request from the attacker with forged IP > > address. Using cookie also doesn't help otherwise > > * the client uses the global IP address > > * the attacker could not sniff the first communication when the client > > sends its cookie > > * the server stores the cookie and its mapping to the IP address of > > the client (this doesn't make sense for NAT as there are more than one > > node behind a single Ip address) > > Well the server does not store any state. All state is stored by the client. The > server uses a the IP address and the client cookie and the server secret to > compute a server cookie. This it adds to the response then discards. > > > Furthermore: > > 3- the server doesn't know the random number used by client to > > calculate client_cookie therefore if the server doesn't store this > > mapping (that in public resolvers it does not make sense) the resolver > > cannot authenticate the client and it also accepts cookies from the > > attacker > > Yes it can. It has all the inputs required to re-compute the server cookie > when there is another query. Unfortunately it cannot. According to my previous paragraph. I would like to think really optimistic but sorry I cannot as I put myself in the shoes of an attacker... > > * training data only temporary solve the problem, only in case the > > attacker doesn't sniff the trained data, but for longer period, both > > node (client and > > server) needs to store state information which is similar to problem > > of other security approaches such as DNS data security that needs to > > keep state information. > > When the client discards the server cookie it has to re-establish it. It is up to > the client to determine the resources it needs. But this resources doesn't really help when the server uses a server_secret as an input to its function. The server cookie is different each time. Although, both uses Diffie-Hellman Key exchange algorithm (and of course need a phase for key cipher agreement and so on) to be on a same page, but it only works for one query and for each query there will be a new value and need a new exchange of the cookies. It also make sense to have an experiment and compare the case where the client uses this approach and not using it. Because I think the time to calculate the cookie for server is the same, if it is not more, as the client try to process the query response from the DNS server and notice that it didn't ask it and it was only a DoS attack. This is because you are adding another processing time which IMO, not necessary as I do not see it can protect the clients according to the arguments. > > The algorithm used by client and server to generate cookies doesn't > > change the attack circumstances. Because there are no way for the > > server to authenticate client. Furthermore, attacker is free to choose > > any IP address and generate its cookie. this will be result in higher > > chance for DoS attack since the server needs to calculate the cookie > > for each request, even though, the time is small but it is bigger than > > when the server does not use cookie > > Yes, it uses some computing resources on the server. You have to compare > them against looking up the cost of looking up the requested data. > > > Unless otherwise, server store every single mapping of clients to > > their cookies (as explained earlier) which is not practical in public > > DNS resolvers specially for IPv6 address that the address space is > > large. what is the database to keep such mapping?? what is the search > > method?? this is also useless because the client IP might be temporary > > or random and changes or the clinet no longer use an IP address. > > Which is why there is no storage on the server. > > > So IMO, as a result it cannot provide the protection it explains in > > the draft. > > It is designed to allow large responses to be returned to the client when they > are legitimate queries and not have large responses returned to the client > when they are forged. This happens in conjuction with other filtering > techniques like response rate limiting and help by leaving the traffic on UDP > instead of moving it to TCP. > > Furthermore, It appears that the assumption of this draft is that the > > attacker cannot sniff the client's and server's messages therefore, it > > cannot forge this message. IMO, this assumption is not true. > > If the attacker cannot sniff the messages between clients and servers, > > it doesn't know also to forge which IP address to have an efficient attack. > > IMO, it is not a true assumption. Attacker starts any attacks by > > having a pre-defined phase to know its victims... > > The attacker starts out by knowing the IP address of the victim. > It then uses DNS servers as amplifiers. In many cases knowing the IP address > of the victim also gives you their recursive server as that is well known. When > this happens you not only have garbage responses being sent to victim of the > amplification attack but you also have there queries being dropped. If the victim is behind the NAT, the attacker only sees the NAT IP address. If the recursive DNS server of the victim has a public address, the attacker can apply its attacks on NAT IP and not the single client IP (unless it also knows what ports map to xxx client) So, IMO, the NAT device is target and therefore, implementation of this mechanism in client doesn't help as the bottleneck is on NAT device. Best, Hosnieh _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
