Moin! On 20 Jul 2015, at 4:39, Mark Andrews wrote: > 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. So does that mean that the server has to do the computation every time it receives a query? Couldn't that be a vector for a DOS attack of an off path attacker, as the processing for this probably is heavier than for normal rate limiting.
> 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. Can you explain how this is better than normal RRL for an attack on an authoritative server? If you give out an truncate answer a legitimate client will retry over TCP, while other clients just get the tiny fraction the attacker send making the attack not worthwhile. > A client with a good server cookie avoids being rate limited. So that doesn't help or even makes these random attacks against resolvers worse as the rate limit will be higher or? > 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 > document that the server cookie may be different in every response > it will not be confused. Hm my understanding of the draft was that a server cookie would be valid for a day. Having a different cookie for every query doesn't make sense for me. Can you please elaborate? Maybe we should continue to look a but closer on how attackers can abuse this protocol before we continue. So long -Ralf _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
