Hi, On Mon, Feb 04, 2013 at 09:02:14PM +0000, Vernon Schryver wrote:
> > Consider that, if you spoof $ISP's resolver addresses > > and perform one of these attacks, then $ISP gets at least degraded > > service during the rate limit period. > > Perhaps I misunderstand, but I think that's wrong in general and based > on the persistent and by now very irritating confusion between client > rate limiting and response rate limiting (RRL). No, it isn't. Suppose that DNSprov provides DNS service on behalf of HiProfile. Suppose that HiProfile has one of those services that is really susceptible to the "no response, kill the page load" problems that the big web presences -- Amazon, Yahoo, Twitter, &c -- keep worrying about. Moreover, because of the usual commercial reasons such services have, the TTLs on HiProfile records are short. Now, suppose that MrISP is a very large US-based cable provider with something like (say) 10% of the domestic market. All MsAttacker needs do to cause significant pain is to send a DoS towards DNSprov with source addresses of MrISP's resolver querying for HiProfile's names. RRL will work, of course, in the sense that it will stop spewing garbage. But it will also rate limit responses to anyone apparently coming from that address. This means that MsAttacker can cause MrISP's resolvers to be rate-limited as long as MsAttacker can keep up the attack for something longer than $TTL on some record for HiProfile. In other words, MsAttacker can cause a short but probably effective DoS against HiProfile, and with a little work can probably cause intermittent outages for a significant percentage of MrISP's customers every few minutes. This is perhaps a less bad attack than before, depending on DNSprov's provisioning; but it is contractually devastating for DNSprov, who promised not to drop queries on the floor for HiProfile, but who has dropped such queries on purpose. One can mitigate this to some extent with various additional epicycles to the RRL approach (and I note that you've done so, and congratulate you in your acumen and creativity), but one cannot solve the fundamental issue, which has to do with very high-value targets and very large communities behind certain high-value resolvers. It's a trade-off. RRL works well in some -- maybe most -- cases, but it's not something one can do in others. That's hardly surprising, I think. > If you think not letting the IETF "improve" and then freeze the > specification will lead to fragmentation and disparate implementations, > then you should oppose an RFC. I wasn't opposing anything. I was trying to clear the ground so that we understood, going in, what the bureaucratic hurdles would be so that we wouldn't have to worry about them when we settled on an approach to pursuing an RFC. I'm neither here to defend nor bury the IETF. I intended only to ask what one wanted to do there _before_ we got the IETF process wheel griding our bones to dust. Best, A -- Andrew Sullivan a...@anvilwalrusden.com _______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
