> > 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. > > > 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. > > > 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. 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. 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. 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. 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). > > > > 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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
