In message <024401d0c2fc$2cc85ce0$865916a0$@rozanak.com>, "Hosnieh Rafiee" writ es: > > > 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. > > But this is confusing. Because the document somehow highlighted the fact > that the attacker has no possibility to sniff the communication between the > DNS server and client and then the document starts talking about attack and > assume that the attacker knows the IP address of the node that is behind > NAT. So this raises the questions. Even one sentence explaining that the > attacker knows this IP address from previous traffic between these nodes > would be helpful.
To attack _you_ I would attack 188.174.236.194 based on the received headers in the email I am relying to. You most probably have a NAT. With a little more investigation I could probably get the recursive servers you are using. Nowhere I seen a packet from you but I know where to direct the attack. There are 1000's of potential ways to find out the address to attack. > > > > > > 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. > > But all the document highlighted NAT scenario. If it is applicable to other > scenarios, then it needs to be mentioned in the document. By reviewing the > document, I had this impression that this mechanism is only for the case > where a client is behind the NAT and all what this mechanism is do is to > somehow protect this client. > Which was the result of so many discussion over the NAT and client Ip > address that is not seen behind the NAT. No the document demonstrated it worked equallt well with client behind a nat the same as it works with clients not behind a nat. > > 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. > > I skimmed RFC 6891 which is the base of this work. IMO what you say here > seems to be in contradiction with that RFC. See section 6-2 of that RFC. > Since cookies are a kind of OPT RR, "they MUST NOT be cached" It doesn't cache the OPT record. Cookies are a EDNS option. They are not the opt record. > And now you're talking about combining this mechanism with DNS EDNS (which > is OPT RR) which help server to recognize the client?! Sorry I am not > convinced with the mechanism in the draft. I have tried to explain my > reasons. I am convinced about having some client side only mechanism and not > as complicated as producing cookies but it can be anything to keep the state > of queries sent to the DNS server. But not convinced of server side > mechanisms to the extend it is explained in the draft. Just to summarize > what seems to add value and what seems not add necessarily any additional > value to the existing systems, I explain everything under two subtitle: > advantages and disadvantages: > > Advantages: > - Good to have a client side mechanism which keep state of its own query and > discard anyone that it doesn't have any state about. So client_cookie to > some extend address this requirement but the problem could be address much > easier. > In other word, this doesn't need necessarily that the client do any special > process to produce cookies. It can be simply by keeping even a sequence > number regarding the query it submitted to DNS server or a bit regarding to > the query. For example if it sends a query to DNS server and waiting for the > response, then the bit is set to false and if it received the response, the > bit is 1. In that case if it receives any DoS attacks (a large number of > queries), the client only checks the bit. When it doesn't expect any > response, without processing the large queries, discard them all. > And ok, for your case that is different and you go through the process of > producing cookie. That is also ok but needs more processing time than simply > assign a bit for each real query and only dependent on the client without > thinking whether or not the server support this approach. > > Disadvantages: > - Not good to have server side part of this mechanism > - If one look at the client cookie and server cookie, there are only some > numbers (ok ok.. they are produced by xx algorithm but actually they are > unrelated numbers.) in other word, the server might not produce the SAME > cookie for the same client because the "server_secret" is different > everytime. So, the server cannot identify the same client by only > calculating the cookie based on the client IP, client cookie and its own > secret. You are just wrong. Given a client cookie of 5601890afd80709 and a client IP address of 1.1.1.1 and a secret of da39a3ee5e6b [rock:~/git/bind9] marka% openssl sha1 5601890afd80709+1.1.1.1+da39a3ee5e6b (stdin)= b293dad995a863793565d5ed88de830269fa4218 [rock:~/git/bind9] marka% now the server sends back 5601890afd80709b293dad995a863793565d5ed88de830269fa4218 the next time the client talks to the server it sends 5601890afd80709b293dad995a863793565d5ed88de830269fa4218 >From which the server extracts 5601890afd80709 and add the IP address which it combines with the secret to compute b293dad995a863793565d5ed88de830269fa4218. Now unless the attacker gets both 5601890afd80709 and the matching IP address right the resulting server hash wont be b293dad995a863793565d5ed88de830269fa4218 > This allows an attacker to still submits query to server with spoof source > IP address of the victim client. So, for server > > [1] What needs the server to keep to make the proposal valuable is that the > server keeps the mapping of server_secret for each client. Therefore, No. > Even with the solution [1], once the attacker submits a query to the server > with spoofed source IP address and has the possibility to eavesdrop the > query response (that he himself originated it with the spoof IP), then he > get to learn server_cookie for this specific client and include it to every > single request it submits to server. So at the end, maybe once it worked , > with considering the fact to keep the mapping on the server (which is not in > the draft and the base of this draft is different) If the attacker can see the reply traffic all bets are off. This is not designed to protect in that senario. The document says it doesn't work in that senario so I fail to see why you are raising it. On path attackers are a completely different kettle of fish. > - RRLs seems to already work to some extend for servers. So, I am not sure > what additional value it adds (my comment is only the server_cookie or > server side mechanism of this draft) > > [2] server might want to use different server_secret even for the same > client to address the problem of [1]. But unfortunately, the server cannot > calculate the same server_cookie for the same client. therefore, this gives > an attacker a big chance to apply its attack as for the result of [4] [5] is > different for the server. So if the server uses RRL, then either the server > uses this mechanism or not, it doesn't help the server nor the client to > authenticate eachother. > > [4] Query 1: server_cookie =Pseudo_function (client_cookie + 192.168.1.1 + > 789999) where server_secret = 789999 ---> server_cookie=a74t54545 > [5] Query 2: server_cookie =Pseudo_function (client_cookie + 192.168.1.1 > + 877766) where server_secret = 877766 ----> server_cookie = b9977005 > > So both [4] and [5] was for the same client but server result cookie is > different. multiple secrets are supported you send back a index to the secret + the computed value in the cookie field server_cookie=01a74t54545 server_cookie=02b9977005 The server know that 01 and 02 are index values to server secrets. > [6] By considering all the above fact, the solution now is keeping the > mapping of client_cookie as well as server_secret in the server so that the > server can differentiate this client from other clients and also the > attacker. > > [6] would work as long as the attacker doesn't get to learn the > client_cookie, if it learns it then it only copy it to each of its request > and for server it is similar to the client. So it is like the server doesn't > know how Alice is look like and alice supposed to receive an important > letter, the attacker can also go to server and say I am Alice. Server asks > for Alice's cookie, but attacker also copy Alice cookie and has it. > therefore, from the server, the attacker is identified as Alice and could > forge the identity of Alice. Alice used cookie but didn't help it. > > Last but not least, since in the draft server_secret is not kept in the > server and there is no client actual authentication as explained in [6], > then the server side mechanism does not help the client. > > So, again back to the problem of such database that needs to keep this > mapping and search over each records for the server. This depends on also > the number of clients that query this server. So if you consider a public > DNS... ... > > > > * 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. > > I think there is misunderstanding. My concern is not why we keep the state > in client. my concern is that the server side part of this mechanism doesn't > work and not helpful. It does work. These are basic cryptographic techniques that are known to work. Go work though some actual examples exactly as they are described. > > 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. > > I don't see any additional value that this draft can bring to the existing > mechanism by including the server side part of the mechanism. Client only > is good and can work with RRLs and other mechanism. > > > > See the logic above for how it helped the client. It got a answer rather > than > > having the query dropped. > > With RRL as you discussed about, it can also receive an answer. If the > client doesn't try to send a lot of messages to server in a short period of > time. It is of course the bad luck of client if the same time as the > attacker starts attack, it also starts requesting any query from the DNS > server. In that case, it doesn't matter whether we have this mechanism, > based on the rate, the server, might also drop the client's request. > > 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
