In message <001201d0c288$317fe330$947fa990$@rozanak.com>, "Hosnieh Rafiee" writes: > > > 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. > > 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. > > > > 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. > > > > 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 does not keep the state. So, how it can identify the client next > time when it starts to communicate to the server? This is not clear to me. I > think I highlighted this fact in all my previous messages. 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. * 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. > If server thinks it communicated with this client before, only based on the > fact that the client also included server cookie, then since the server does > not store any state and each time the server might generate a new cookie, > then the attacker can create a fake cookie using the similar way as the > server generates its own cookie. That is : > fake_server_cookie=(fake_client_cookie + IP client (victim) + > attacker_secret) . It also generates a fake_client_cookie and in this way it > pretends that it had a previous communication with server. Since server is > not aware of the fact (no state in the storage), the server assumes that it > had a communication with this client before. No. The server takes the fake_client_cookie + IP client (victim) + server secret + maybe parts of server cookie itself. Computes a server cookie and compares that with what was received. If and only if that matches (1 in 2^64) does the fake query get treated legitimate. > Therefore, it answers the > attacker requests. The attacker does this with different values by > requesting large queries from the server but with spoofed source IP address > that is the source IP address of the client and still can perform the > amplification attack. 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. A client with a good server cookie avoids being rate limited. A cookie client with a bad/no server cookie gets a non/minimally amplified (add server cookie size) badcookie response rather then a TC=1 response after going through the rate limiter. A server can choose to always send badcookie if there is no server cookie in the cookie opt or there was a server cookie mis-match rather than adding the answer along with a good server cookie for queries received over UDP. This is possible whereas setting TC=1 on all UDP responses isn't. > Now about the client, it will be overwhelmed with a lot of query responds > from the server. since the client stored the previous server_cookie but the > server_cookie might be different for each query. Therefore, the client might > be puzzled and it starts processing server messages. So, the attacker seems > to be successful. The client only checks its client cookie. It stores the new server cookie if it got a good response. Given the client knows from this document that the server cookie may be different in every response it will not be confused. > Therefore, the existence of server cookie did not help the client. So, I > would back to the previous simple example that is client only mechanism (the > following .. with considering the fact that the attacker no need to have a > miracle to know the IP of the client). See the logic above for how it helped the client. It got a answer rather than having the query dropped. > > > 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 > 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. > > > > > > . > > > > 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. > > > > Thanks > > > Some editorial comments: > Others might have different opinion, but while I was reading the draft, > after reviewing introduction, suddenly the attacks starts which still there > is nothing about the mechanism. So, I had to skip that section, review the > mechanism and back to attack sections. So, maybe it would be good to move it > to after the explanation of the mechanism?! > > 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
