Hello, I have reviewed this draft. My comments are as followings:
- Section 3.2 <snip> TKEY can solve the problem ..</snip> IMO TKEY also needs some manual preconfiguration on the server side. So, it does not completely solve the TKEY distribution problem. furthermore This is only applicable to recursive resolvers and authoritavie servers.Therefore, for client communications, it has the same barriers as DNSSEC has for clients (trusted anchors,etc.) If the victim node is behind NAT (servers are not behind NAT), and attacker is not in the same network, IMO, it cannot perform any amplification or DoS attack on the victim node. unless otherwise, the attacker is aware of the communication and ports used for the clients behind the NAT. Therefore, the use of this mechanism is not applicable in such situation. Therefore, I do not see any use case for nodes behind NAT. If the client has a global IP address, for example if it uses IPv6 that usually the IP address is global, then the attacker has a possibility to perform the DoS attack even though the client uses this method. because: - As far as I understood from the method, It is similar to enclosed figures (the algorithm is only arbitrary algorithm but this really does not matter). The problem is that still amplification and spoofing or any attacks explained in the draft is possible The reasons are as follows: 1- client doesn't know the random number used by the server to calculate the servers' cookie response. if it needs to know then it returns to the barrier of sharing this value between clients and servers 2- The server has no way to authenticate the client. so, it also accepts any arbitrary request from the attacker with forged IP address. Using cookie also doesn't help otherwise * the client uses the global IP address * the attacker could not sniff the first communication when the client sends its cookie * the server stores the cookie and its mapping to the IP address of the client (this doesn't make sense for NAT as there are more than one node behind a single Ip address) Furthermore: 3- the server doesn't know the random number used by client to calculate client_cookie therefore if the server doesn't store this mapping (that in public resolvers it does not make sense) the resolver cannot authenticate the client and it also accepts cookies from the attacker * training data only temporary solve the problem, only in case the attacker doesn't sniff the trained data, but for longer period, both node (client and server) needs to store state information which is similar to problem of other security approaches such as DNS data security that needs to keep state information. The algorithm used by client and server to generate cookies doesn't change the attack circumstances. Because there are no way for the server to authenticate client. Furthermore, attacker is free to choose any IP address and generate its cookie. this will be result in higher chance for DoS attack since the server needs to calculate the cookie for each request, even though, the time is small but it is bigger than when the server does not use cookie Unless otherwise, server store every single mapping of clients to their cookies (as explained earlier) which is not practical in public DNS resolvers specially for IPv6 address that the address space is large. what is the database to keep such mapping?? what is the search method?? this is also useless because the client IP might be temporary or random and changes or the clinet no longer use an IP address. So IMO, as a result it cannot provide the protection it explains in the draft. Furthermore, It appears that the assumption of this draft is that the attacker cannot sniff the client's and server's messages therefore, it cannot forge this message. IMO, this assumption is not true. If the attacker cannot sniff the messages between clients and servers, it doesn't know also to forge which IP address to have an efficient attack. IMO, it is not a true assumption. Attacker starts any attacks by having a pre-defined phase to know its victims... In general, based on my understanding from the mechanism, it does not protect what it supposed to protect and It only adds a new data to the DNS messages and includes processing times without providing the mentioned value. If I mis-understood the mechanism please explain. thanks, Best, Hosnieh
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
