| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <4B0FBC75.5060000@gmail.com> Date: Fri, 27 Nov 2009 12:48:05 +0100 From: Eric Dumazet <eric.dumazet@...il.com> To: Ilpo Järvinen <ilpo.jarvinen@...sinki.fi> CC: Krzysztof Oledzki <ole@....pl>, David Miller <davem@...emloft.net>, Herbert Xu <herbert@...dor.apana.org.au>, Linux Netdev List <netdev@...r.kernel.org> Subject: Re: Problem with tcp (2.6.31) as first, http://bugzilla.kernel.org/show_bug.cgi?id=14580 Ilpo Järvinen a écrit : > What would you expect to happen? If out-of-window stuff arrives we send > dupacks. If we would send resets, that would introduce blind rst attacks. > In theory we might be able to quench the loop by using pingpong thing but > that needs very careful thought in order to not introduce other problems, > and even then your connections will not be re-usable until either end > times out so the gain is rather limited. We simply cannot rst the > connection, that's not an option. > > I find this problem simply stem from the introduced loss of end-to-end > connectivity. Would you really "lose" that server so that its TCP state is > not maintained, you'd get resets etc (crash, scheduled reboot or > whatever). Only real solution would be a kill switch for TCP connection > when you break e-2-e connectivity (ie., switch servers so that the same IP > is reacquired by somebody else). In theory you can "simulate" the kill > switch by setting tcp_retries sysctls to small values to make the > connections to timeout much faster, but still that might not be enough for > you (and has other implications you might not like). > RST is not an option, sure, but ACK storms are unlikely good things too. Could'nt we do something smart in presence of tcp timestamps ? 11:23:27.669910 IP 192.168.20.110.3434 > 192.168.200.200.333: . ack 2457299512 win 92 <nop,nop,timestamp 42408589 1506086404> 11:23:27.669991 IP 192.168.200.200.333 > 192.168.20.110.3434: . ack 11687 win 91 <nop,nop,timestamp 1704614538 42406583> 11:23:27.670000 IP 192.168.20.110.3434 > 192.168.200.200.333: . ack 2457299512 win 92 <nop,nop,timestamp 42408589 1506086404> 11:23:27.670093 IP 192.168.200.200.333 > 192.168.20.110.3434: . ack 11687 win 91 <nop,nop,timestamp 1704614538 42406583> 11:23:27.670099 IP 192.168.20.110.3434 > 192.168.200.200.333: . ack 2457299512 win 92 <nop,nop,timestamp 42408589 1506086404> 11:23:27.670175 IP 192.168.200.200.333 > 192.168.20.110.3434: . ack 11687 win 91 <nop,nop,timestamp 1704614538 42406583> 11:23:27.670183 IP 192.168.20.110.3434 > 192.168.200.200.333: . ack 2457299512 win 92 <nop,nop,timestamp 42408589 1506086404> 11:23:27.670268 IP 192.168.200.200.333 > 192.168.20.110.3434: . ack 11687 win 91 <nop,nop,timestamp 1704614538 42406583> 11:23:27.670276 IP 192.168.20.110.3434 > 192.168.200.200.333: . ack 2457299512 win 92 <nop,nop,timestamp 42408589 1506086404> 11:23:27.670359 IP 192.168.200.200.333 > 192.168.20.110.3434: . ack 11687 win 91 <nop,nop,timestamp 1704614538 42406583> 11:23:27.670368 IP 192.168.20.110.3434 > 192.168.200.200.333: . ack 2457299512 win 92 <nop,nop,timestamp 42408589 1506086404> Or we could Count number N of strange/bad acks we received from peer. - At first one, send our ACK immediately - For following, delay our ACK answer by N*100 ms, to reduce the flood. (or if we have data in flight, only rely on retransmit timer and not sending acks) -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists