<html><head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head><body style="font-family: tt; font-size: 11pt;" bgcolor="#FFFFFF"
text="#000000"><div style="font-size: 11pt;font-family: tt;"><span
style="font-family: monospace;">sorry for the delay in getting back to
this thread. i know damian raised some important points.</span><br><br>Damian
Menscher wrote:<blockquote
cite="mid:CABSP1Of0X-zJdU4+WmjAKxDtqyOEC8okTUSgiG1kBcmsH85+RQ@mail.gmail.com"
type="cite"><div dir="ltr"><div class="gmail_extra"><div
class="gmail_quote">On Thu, Feb 6, 2014 at 4:46 PM, Paul Vixie <span
dir="ltr"><<a moz-do-not-send="true" href="mailto:paul@redbarn.org"
target="_blank">paul@redbarn.org</a>></span> wrote:<br><blockquote
class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Damian Menscher wrote:<br>
> ...<br>
<div class="im">> My recommendation (which Vixie and Vernon disagree
with) is to use RRL<br>
> with slip=1 -- return TC=1 responses to all queries over the limit.<br>
<br>
</div>my disagreement is explained in detail here:<br>
<a moz-do-not-send="true"
href="http://www.circleid.com/posts/20130913_on_the_time_value_of_security_features_in_dns/"
target="_blank">http://www.circleid.com/posts/20130913_on_the_time_value_of_security_features_in_dns/</a></blockquote><div><br>
</div><div>Since I haven't explained my objections before, I'll pick
apart your arguments:</div><div><br></div><div>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.</div></div></div></div></blockquote><br>no. there are two
classes of attackers: those who understand and innovate, vs. those who
just follow well trodden paths. the attackers we mostly see are of the
second variety, but our defenses must take account of both varieties.<br><br><blockquote
cite="mid:CABSP1Of0X-zJdU4+WmjAKxDtqyOEC8okTUSgiG1kBcmsH85+RQ@mail.gmail.com"
type="cite"><div dir="ltr"><div class="gmail_extra"><div
class="gmail_quote"><div> If they wanted to amplify packets/second they
could just spoof syn packets to webservers.</div></div></div></div></blockquote><br>and
they will, when we force them to, which is my goal in the DNS RRL work.
forcing the attacker to adopt a more complex technique is not a pure
win but i'll take it.<br><br><blockquote
cite="mid:CABSP1Of0X-zJdU4+WmjAKxDtqyOEC8okTUSgiG1kBcmsH85+RQ@mail.gmail.com"
type="cite"><div dir="ltr"><div class="gmail_extra"><div
class="gmail_quote"><div> Returning to a 1:1 ratio should be our goal,
and slip=1 achieves that.</div></div></div></div></blockquote><br>my
goal is as stated, attenuation of both packets and bits, for the reasons
i've stated. if the attacker is willing to accept 1:1 then they can
forge packets directly to the victim. i want to encourage that, by being
a worse alternative for them than reflecting through my server. i won't
try to talk you out of your chosen goal, so long as you clearly state
it when making recommendations in keeping with it.<br><br><blockquote
cite="mid:CABSP1Of0X-zJdU4+WmjAKxDtqyOEC8okTUSgiG1kBcmsH85+RQ@mail.gmail.com"
type="cite"><div dir="ltr"><div class="gmail_extra"><div
class="gmail_quote">
<div><br></div><div>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.</div></div></div></div></blockquote><br>no. actual
query load as witnessed on dns servers i have operated even 15+ years
ago was not sustainable via tcp due to state load.<br><br><blockquote
cite="mid:CABSP1Of0X-zJdU4+WmjAKxDtqyOEC8okTUSgiG1kBcmsH85+RQ@mail.gmail.com"
type="cite"><div dir="ltr"><div class="gmail_extra"><div
class="gmail_quote"><div> 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.</div></div></div></div></blockquote><br>anyone on
the internet can exhaust the tcp listener quota of any dns server they
target, thus ensuring that tcp fallback temporarily fails for other
victims whom they are simultaneously trying to starve via an RRL flow
overrun. that's what i mean by "tcp fragility". any design that calls
for tcp fallback of dns is by definition too fragile to be used in
production. (that's why i criticized nominum's answer to the kaminsky
attacks back in 2008, too.)<br><br><blockquote
cite="mid:CABSP1Of0X-zJdU4+WmjAKxDtqyOEC8okTUSgiG1kBcmsH85+RQ@mail.gmail.com"
type="cite"><div dir="ltr"><div class="gmail_extra"><div
class="gmail_quote">
<div><br></div><div>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,</div></div></div></div></blockquote><br>you
work at google. in my world, a 100Mbit/sec attack is noticeable. in
your world, it doesn't even raise an eyebrow.<br><br><blockquote
cite="mid:CABSP1Of0X-zJdU4+WmjAKxDtqyOEC8okTUSgiG1kBcmsH85+RQ@mail.gmail.com"
type="cite"><div dir="ltr"><div class="gmail_extra"><div
class="gmail_quote"><div> 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?</div></div></div></div></blockquote><br>there
may be a marked difference in our perspective. i went along with
bernstein-style source port randomization as a temporary work around to
the kaminsky bug back in 2008, because we had to have something, and it
was something. the real fix, as i said then, is dnssec. other real
fixes, like eastlake-style cookies, or several proposals i'm aware of
which havn't been published as yet, might also come. but in no case did i
sign up for, nor will i accept an indefinite future where, cache
poisoning remains feasible using sustained flows of 100Mbit/sec for five
to fifteen minutes.<br><br>that means the risk which you claim is
non-negligible and unnecessary, i claim is both negligible and a sunk
cost. so, i won't spend new manna on it. especially if to get additional
traction on it i would have to accept a defense strategy for reflection
that made me no less attractive than sending spoofed packets directly
to the victims.<br><br>i think my article covers pretty well the topic
of why reflection is a separate boon for attackers, over and above
amplification.<br><br>see also the followup acm queue article at
<a class="moz-txt-link-rfc2396E" href="http://queue.acm.org/detail.cfm?id=2578510"><http://queue.acm.org/detail.cfm?id=2578510></a>.<br><br><blockquote
cite="mid:CABSP1Of0X-zJdU4+WmjAKxDtqyOEC8okTUSgiG1kBcmsH85+RQ@mail.gmail.com"
type="cite"><div dir="ltr"><div class="gmail_extra"><div
class="gmail_quote">
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div
class="im">
> This ensures your legitimate users can get through with a TCP
request,<br>
> rather than having to attempt multiple retries before learning to<br>
> retry over TCP. Does slip=1 address your concerns?<br>
><br>
> Of course TCP isn't perfect -- it has higher latency and<br>
> per-connection costs -- but at least it ensures your legitimate
users<br>
> can't be affected by the RRL.<br>
<br>
</div>it does not. see [ibid].<br></blockquote><div><br></div><div>Do
you have additional arguments I missed?</div></div></div></div></blockquote><br>apparently
so.<br><br>vixie<br></div></body></html>