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