Hi, I think Mark has done a good job in responding, so I don't really have much to add.
If you can conveniently do configuration at the client and server, then you can get strong authentication with TSIG. If you can't, the weak authentication provided by Cookies is about the best you can do. See below On Sun, Jul 19, 2015 at 10:39 PM, Mark Andrews <ma...@isc.org> wrote: > > 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. Even though it is not a good idea, I believe there are many small recursive DNS servers behind a NAT that are queryable from the Internet and findable through NS RRs. An attacker can try to poison the cache at such a server and even if bandwidth to such a server is limited there are many of them and they can be used in amplification attacks. In any case, whether it is a common or a rare case, since you can extend the weak protection to such cases fairly easily be including the client cookie in the computation of the server cookie, why not? >> > > > 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 The "attacker_secret" has only a 1 in 2**64 chance of being the same as the server's secret so the server cookie will be wrong so the server will not treat the request as authenticated. It is up to the server what to do in this case which is pretty much the same case as a request with no server cookie. Presumably the server will not send back a big answer (to avoid amplification) and will not do a lot of work (for example, will not send recursive queries or the like) to avoid being saturated with processing fake queries. That the attacker has to generate a fake client cookie to stick into the 64-bit client cookie field is not very relevant since the client cookie is opaque to the server and just gets reflected back in the response, if the server chooses to send a response. >> 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. Right. >> 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 Where good response includes having a correct client cookie. > 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. As per the Kaminsky attack, it is relatively easy to cause a recursive resolver to issue queries for known DNS names so the response check in your example is much weaker than you think, much weaker than DNS Cookies. >> > 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?! It seems to me that presenting the defenses before the attacks means that while you are reading the defenses they are un-motivated. I think the current organization is better for a general technical audience. Problem then solution, as in the current draft, just seems most logical to me. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com >> 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
