In message <000301d0c17f$6ac5f530$4051df90$@rozanak.com>, "Hosnieh Rafiee" writes: > > 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.
It can DoS the path to the NAT. All the attacker needs is the public address of the NAT. For the DoS stream to go through the NAT assuming it is a stateful NAT then yes the attacker needs more knowledge. > 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 The client sends queries only with client cookies initially. These are treated like any other unauthenticated query. They are subject to rate limiting of responses and sending back minimal responses (rcode=BADCOOKIE or TC=1). > 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) Well the server does not store any state. All state is stored by the client. The server uses a the IP address and the client cookie and the server secret to compute a server cookie. This it adds to the response then discards. > 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 Yes it can. It has all the inputs required to re-compute the server cookie when there is another query. > * 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. When the client discards the server cookie it has to re-establish it. It is up to the client to determine the resources it needs. > 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 Yes, it uses some computing resources on the server. You have to compare them against looking up the cost of looking up the requested data. > 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. Which is why there is no storage on the server. > So IMO, as a result it cannot provide the protection it explains in the > draft. It is designed to allow large responses to be returned to the client when they are legitimate queries and not have large responses returned to the client when they are forged. This happens in conjuction with other filtering techniques like response rate limiting and help by leaving the traffic on UDP instead of moving it to TCP. > 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... The attacker starts out by knowing the IP address of the victim. It then uses DNS servers as amplifiers. In many cases knowing the IP address of the victim also gives you their recursive server as that is well known. When this happens you not only have garbage responses being sent to victim of the amplification attack but you also have there queries being dropped. > 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 > -- 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
