In message <000001d0c225$8c4d0260$a4e70720$@rozanak.com>, "Hosnieh Rafiee" writes: > > > 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. > > When the clients are not seen, I just wonder how the attacker can target > them??
Clients talks to things other than DNS servers. The attacker gets the address of the address of the client from those transactions. > NAT device doesn't know what to do with packets that coming from a xx > machine that the source address is its own address without seeing any more > information regarding ports, etc. so that it can redirect the requests to > the target client. Either our definition from NAT device is different that > is we are talking about two different device with two different > functionality or there is a new generation of NAT devices that are so > intelligent and know what to do when they receive undefined packets. There are two ends to the communication between the client and the DNS server it is querying. DNS COOKIES helps servers pick legitimate client queries out of spoofed traffic. > > > 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*. > > Might be, but this is also not applicable. But you just suggested that the NAT box do that. > > 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. > > If the client does not check the server cookie in a initial step, then why > don't you send anything to server so that the server needs also to do some > processes which, of course, need processing time and this is vital for the > server. Take it easy and Only keep the state in your client similar to the > following simple example and do not bother server as based on the arguments > and the explanation in the draft, the involvement of the server doesn't help > neither in authenticating the server nor doing any prevention of attacks. In > other word, the server only do some steps that is not necessarily help the > client. (this conclusion is according to your own explanation such as : The server does the steps so that it can identify the client when it talks to the server again. This both helps the client and server. > > The server is free to use different algorithms to generate it's key. > > DNS COOKIE doesn't specify the exact algorithm to use. > > > > Simple Example that has the same impact as dnsop-cookies mechanism: > Client A sends a query to DNS server A. Client A stores the state (e.g. > query for www.example.com status: sent response: false) > The DNS server responds this client with the query response. Client checks > its state storage and found that the "response" value was false. So it > accepts the value from the server since it was waiting for a response. Then > remove this state from its state storage as it no longer needs to ask any > query. > Now, the bad guy wasn't aware of those communication but, with a miracle, > found that what IP address is used by Client A so that he can target this > client who is behind the NAT. So the bad guy sends a lot of query requests > to the server with spoofed client IP address as a source address. DNS server > sends query responds to the victim client (Client A). Victim client only > check its state storage and found that it never request for any query. So, > it silently discard all queries. > > Now about miracle part, I do not know how the attacker can obtain the IP > address of the client without sniffing the communication or has a > possibility to eavesdrop. If he can eavesdrop, then he also can know all the > information exchanged between client and the server. 99.999% of DNS recursive amplifiying attacks result from non DNS transactions which give away the address of the client. No sniffing required. > Therefore, I am still confused that how this scenario, even the simplest one > in my example, works behind the NAT. It works without NAT. > > I am also considering all possibilities such as the case the attacker is > also behind the same NAT. In that case, there is a higher chance for the > attacker to sniff the whole communication and even sends the query request > immediately to the DNS server the same time as the client sends a request to > the DNS server. Therefore, the client would be overwhelmed with many query > response from the DNS server to its request. In that case, the simple > example might not work too. > > > > > > 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) > > Doesn't really different. As a mistake I forgot to include the IP address of > client. but in my first figure it exists. > > > 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. > > > > > > > > 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. > > So please share the results. I am so curious. All versions of BIND 9.10 support a variant of DNS COOKIE called SIT. This is a experimental compile option and is enabled by default in the Windows binaries we ship. https://source.isc.org for the git repository. > 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
