In message <3c8b970b-4588-4f31-ab35-436b7cbb5...@fl1ger.de>, "Ralf Weber" write s: > 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.
Yes. Potentially it depends on the algorithm used to create the hash and what paths are executed on success / failure. It also depend on the interface speed / cpu speed etc. > > 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. Please go re-read what I have already sent out. > > 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? Unparseable. > > 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? Validity time of a server cookie is independent of when a new cookie is generated. Named hands out a new server cookie on every response. Each of those cookies is valid for a given time. > Maybe we should continue to look a but closer on how attackers can abuse > this protocol before we continue. > > So long > -Ralf -- 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
