In message <001501d0c1ec$52898050$f79c80f0$@rozanak.com>, "Hosnieh Rafiee" writes: > 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.
It helps those clients behind the NAT that implement cookies. > 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. Having middle boxes modify packets is a *bad* *idea*. > > > 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. The client doesn't check the server cookie returned. It just stores it. The client checks the client cookie. The server checks the server cookie. > 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) Server_cookie=Pseudo_function(client cookie+client address+server secret) The client checks the client cookie *before* accepting the server 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. No. The attacker doesn't see the reply traffic from the 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... Yet, we have code that does this. > > > * 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. No. > 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. The server is free to use different algorithms to generate it's key. DNS COOKIE doesn't specify the exact algorithm to use. > 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. It helps the clients that use it. > Best, > Hosnieh > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
