<div dir="ltr">Of course *does make me uneasy*.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 15, 2015 at 10:33 PM, Federico Schwindt <span dir="ltr"><<a href="mailto:fgsch@lodoss.net" target="_blank">fgsch@lodoss.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">The original 3 seconds is from 1989. <br><br>I don't believe that a 26 years old value is a sound argument to bump it to 7 seconds IMO.<br><br>This does not mean the default is correct, however, but increasing it 3.5 times doesn't make me uneasy considering the security implications.<br><br>My 2 cents.<br><br><br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 15, 2015 at 5:36 PM, Nils Goroll <span dir="ltr"><<a href="mailto:slink@schokola.de" target="_blank">slink@schokola.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
some time has passed since my initial email regarding this suggestion and it<br>
still holds.<br>
<br>
Unless there is a strong argument against it, I think we really should increase<br>
the default timeout_req to 7 seconds. I think the argumentation for this value<br>
is sound and I haven't found any reasons against it.<br>
<br>
Please keep this suggestion separate from the suggestion to re-introduce<br>
SO_LINGER. I still need to do production system tests with it.<br>
<br>
Nils<br>
<br>
On 26/02/15 11:27, Nils Goroll wrote:<br>
> This tcpdump output illustrates an issue we seem to have with default Linux tcp<br>
> timeouts and the default timeout_req of 2 seconds:<br>
><br>
> 16:47:44.542049 IP client.49550 > varnish.80: Flags [S], seq 29295818, win 4380,<br>
> options [mss 1460,sackOK,eol], length 0<br>
> 16:47:44.542080 IP varnish.80 > client.49550: Flags [S.], seq <a href="tel:3652568857" value="+13652568857" target="_blank">3652568857</a>, ack<br>
> 29295819, win 29200, options [mss 1460,nop,nop,sackOK], length 0<br>
> 16:47:44.542250 IP client.49550 > varnish.80: Flags [.], ack 1, win 4380, length 0<br>
> 16:47:46.080501 IP client.49550 > varnish.80: Flags [P.], seq 1:1453, ack 1, win<br>
> 4380, length 1452<br>
> 16:47:46.080528 IP varnish.80 > client.49550: Flags [.], ack 1453, win 31944,<br>
> length 0<br>
> 16:47:48.082783 IP varnish.80 > client.49550: Flags [F.], seq 1, ack 1453, win<br>
> 31944, length 0<br>
> 16:47:48.083070 IP client.49550 > varnish.80: Flags [.], ack 2, win 4380, length 0<br>
> 16:47:48.350763 IP client.49550 > varnish.80: Flags [P.], seq 1453:2905, ack 2,<br>
> win 4380, length 1452<br>
> 16:47:48.350792 IP varnish.80 > client.49550: Flags [R], seq <a href="tel:3652568859" value="+13652568859" target="_blank">3652568859</a>, win 0,<br>
> length 0<br>
><br>
> The packet at 16:47:46.080501 contains the first part of a request up to the<br>
> start of a very long cookie line.<br>
><br>
> At 16:47:48 varnish closes after reaching timeout_req of 2s. Then, the client<br>
> immediately acks.<br>
><br>
> My understanding is that the varnish->client ack 1453 got lost and the client<br>
> did not get around to retransmit seq 1:1453 before we timed out.<br>
><br>
><br>
> The most helpful online reference regarding recommended initial tcp<br>
> retransmittion timeouts I have found so far is<br>
> <a href="http://tools.ietf.org/html/rfc6298#ref-PA00" target="_blank">http://tools.ietf.org/html/rfc6298#ref-PA00</a><br>
><br>
> In summary, an initial timeout (RTO) of 1s is now recommended, but the former 3s<br>
> RTO remains valid. So, for any client following the former 3s recommendation,<br>
> current we don't even tolerate a single packet retransmission after 3way is<br>
> complete. For those clients following the new 1s recommended RTO, timing is also<br>
> really tight it seems unlikely that we tolerate retransmission of two packets.<br>
><br>
> Based on this, I'd suggest to raise the default timeout_req to 7 seconds to<br>
> allow for two retransmissions at RTO=3.<br>
><br>
> This seems to be particularly relevant with the growing popularity of mobile<br>
> clients.<br>
><br>
> The risk is increased resource usage for malicious requests. To address it, I'd<br>
> suggest to document that lowering timeout_req can be an option to mitigate<br>
> certain DoS (slowloris) attacks.<br>
><br>
><br>
> Nils<br>
><br>
><br>
> _______________________________________________<br>
> varnish-dev mailing list<br>
> <a href="mailto:varnish-dev@varnish-cache.org" target="_blank">varnish-dev@varnish-cache.org</a><br>
> <a href="https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev" target="_blank">https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev</a><br>
><br>
<br>
_______________________________________________<br>
varnish-dev mailing list<br>
<a href="mailto:varnish-dev@varnish-cache.org" target="_blank">varnish-dev@varnish-cache.org</a><br>
<a href="https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev" target="_blank">https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev</a><br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>