Why include DNS client cookie in DNS server cookie computation?

Question

The proposed standard for DNS cookies specifies that the server cookie is to be computed as follows:

The Server Cookie SHOULD consist of or include a 64-bit or larger pseudo-random function of the request source IP address, the request Client Cookie, and a secret quantity known only to the server.

The reasoning provided for the inclusion of the client cookie is as follows:

However, NAT devices sometimes also map ports. This can cause multiple DNS requests and responses from multiple internal hosts to be mapped to a smaller number of external IP addresses, such as one address. Thus there could be many clients behind a NAT box that appear to come from the same source IP address to a server outside that NAT box. If one of these were an attacker (think Zombie or Botnet), that behind-NAT attacker could get the Server Cookie for some server for the outgoing IP address by just making some random request to that server. It could then include that Server Cookie in the COOKIE OPT of requests to the server with the forged local IP address of some other host and/or client behind the NAT box. (Attacker possession of this Server Cookie will not help in forging responses to cause cache poisoning as such responses are protected by the required Client Cookie.)

To fix this potential defect, it is necessary to distinguish different clients behind a NAT box from the point of view of the server. It is for this reason that the Server Cookie is specified as a pseudo-random function of both the request source IP address and the Client Cookie. From this inclusion of the Client Cookie in the calculation of the Server Cookie, it follows that a stable Client Cookie, for any particular server, is needed. If, for example, the request ID was included in the calculation of the Client Cookie, it would normally change with each request to a particular server. This would mean that each request would have to be sent twice: first to learn the new Server Cookie based on this new Client Cookie based on the new ID and then again using this new Client Cookie to actually get an answer. Thus the input to the Client Cookie computation must be limited to the server IP address and one or more things that change slowly such as the client secret.

What is the attack that this is supposed to protect against? And how does it achieve said protection?

The three attacks mentioned in the document are:

• DNS Amplification Attacks
• DNS Server Denial-of-Service
• Cache Poisoning and Answer Forgery Attacks

But as far as I can tell the inclusion of client cookie in the server cookie calculation cannot be addressing any of those.

DNS amplification attacks where attacker and victim are behind the same NAT will still be possible. When the attacker has received the server cookie, he can simply start spoofing the IP of the victim while using client cookie and server cookie exchanged with the server previously. Because client and victim are behind the same NAT, the change in client IP address will be invisible to the server. Thus the client cookie still maps to the same server cookie, and the attack will succeed.

In the case of DNS Server DoS, the aim of the cookies is just to ensure that the server will know the correct IP address of whoever is performing the attack. When attacker is behind a NAT, the server will see the IP address of that NAT regardless of what spoofing the attacker performs behind the NAT. And the cookies don't change that.

In the case of forged replies, the protection is provided by the client cookie of the victim which remains unknown to the attacker. So regardless of how the server cookie is computed, this attack would fail. Moreover forged replies are by definition not generated by the server thus there will be no validation of the server cookie anyway.

So if the inclusion of client cookie in server cookie computation isn't done for one of those three reasons, then what is the purpose of it?

Answer 1

If I understand it correctly adding the client IP address to the servers cookie is used to protect against source spoofing attacks against a client which is behind the same NAT as the attacker.

If the server cookie is only associated with the external IP address of the NAT then the internal attacker could make a valid request to the server to get a server cookie which is valid for all clients behind the same NAT. Then the attacker could create a request with the spoofed source IP address set to the internal victims IP address. The NAT gateway will replace the source IP to the external IP when talking to the server. The response from the server will then be forwarded by the NAT gateway back to the alleged sender of the request, i.e. the victim. But since the request contained the server cookie the server assumes that it communicates with an authenticated victim and will switch off amplification protection.

By associating the client cookie with the server cookie and including both client cookie and server cookie in the request the server can validate that the request is really from the same client which got the server cookie before and not some other client behind the same NAT gateway. Only if the attacker is able to get the client cookie he will be able to mount an attack against the client. But to do this the attacker must be able to sniff the network traffic which needs more resources and permissions and is thus explicitly excluded in the attack scenario. From section 9 of the draft:

9. Security Considerations

DNS Cookies provide a weak form of authentication of DNS requests and responses. In particular, they provide no protection against "on- path" adversaries; that is, they provide no protection against any adversary that can observe the plain text DNS traffic, such as an on- path router, bridge, or any device on an on-path shared link (unless the DNS traffic in question on that path is encrypted).