Hi Ralf, On Mon, Jul 20, 2015 at 7:19 AM, Ralf Weber <d...@fl1ger.de> wrote: > 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.
I do not think that is a significant problem if you use a lightweight hash algorithm like FNV or even a strong cryptographic algorithm if you have hardware support for the algorithm. It is up to the server what algorithm to use and if you have an especially feeble server (although why you would have a DNS server on such a device is not clear to me), you could go for some really stupid hash function like just XORing or adding 32-bit chunks or the like, which would still be conformant. While the protocol is designed so that no state needs to be maintained at the server, I don't think that sort of approach isn't explicitly prohibited. But I think it would be more work for the server to remembers lots of server cookies it has sent than to do simple calculation. Still, it is an implementation choice. >> 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. There is overhead in more messages and in state to do TCP and you get less authentication, in my opinion, than you can get with 64-bit cookies. >> 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? ? Only legitimate clients that should not be rate limited will have a good server cookie they can use. I don't understand what you are saying about random attacks? >> 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? See Mark's answer. The only mandatory secret rollover provision in the draft is that the local secret MUST be changed once a month (plus a few days to allow for weekends / holidays, etc.). If you have a fancier server cookie format like that shown in Appendix B.2, the server cookie includes an authenticated time stamp so the server could choose any time bound shorter than the server secret rollover time and could even dynamically adjust that time bound if it wanted to. Or a server can just rollover its secret more often if it wants. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com > 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
