[dns-operations] rate-limiting state

[Damian Menscher]

On Thu, Feb 6, 2014 at 4:46 PM, Paul Vixie <paul at redbarn.org> wrote:

> Damian Menscher wrote:
> > ...
> > My recommendation (which Vixie and Vernon disagree with) is to use RRL
> > with slip=1 -- return TC=1 responses to all queries over the limit.
>
> my disagreement is explained in detail here:
>
> http://www.circleid.com/posts/20130913_on_the_time_value_of_security_features_in_dns/


Since I haven't explained my objections before, I'll pick apart your
arguments:

1) "RRL must be attenuative in packets per second, not just in bits per
second".  The attacker is using DNS amplification specifically to increase
bits/second.  If they wanted to amplify packets/second they could just
spoof syn packets to webservers.  Returning to a 1:1 ratio should be our
goal, and slip=1 achieves that.

2) "A pure TCP fallback strategy would be less reliable due to the
fragility of TCP/DNS".  You go on to argue that the 3-way handshake adds
latency and server load, which I agree with.  But keep in mind only the
legitimate queries will need to use TCP, so the actual load is low.  And
these are queries which would otherwise have had to retry over UDP after a
timeout (and even then only have a 50% success rate), so the amortized
latency hit isn't particularly significant either.

3) [Addressing the increased poisoning risk], "requires many hours of
uninterrupted 100 Mbit/sec blasting from the attacker to the victim in
order to have a chance at success".  I don't worry about 100Mbps attacks,
but in the age of 10Gbps (unamplified) attacks, I think this does introduce
a non-negligible (and unnecessary!) risk for high-value domains.  Keep in
mind a single poison packet can inject a high TTL to cause a long outage,
and potentially use that time to steal unencrypted data (SMTP, for
example).  Why take that risk just to reduce the amplification factor
*below* 1:1?

> This ensures your legitimate users can get through with a TCP request,
> > rather than having to attempt multiple retries before learning to
> > retry over TCP.  Does slip=1 address your concerns?
> >
> > Of course TCP isn't perfect -- it has higher latency and
> > per-connection costs -- but at least it ensures your legitimate users
> > can't be affected by the RRL.
>
> it does not. see [ibid].
>

Do you have additional arguments I missed?

Damian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20140206/a32c98ce/attachment.html>