Date: Sun, 7 Nov 1999 08:09:03 -0600 From: Jonathan Lemon <jlemon@americantv.com> To: Dag-Erling Smorgrav <des@flood.ping.uio.no> Cc: "Kenneth D. Merry" <ken@kdm.org>, current@freebsd.org Subject: Re: TCP sockets stuck in the CLOSING state Message-ID: <19991107080903.23572@right.PCS> In-Reply-To: <xzpogd61njn.fsf@flood.ping.uio.no>; from Dag-Erling Smorgrav on Nov 11, 1999 at 01:41:48PM %2B0100 References: <199911052219.PAA01743@panzer.kdm.org> <xzpogd61njn.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 11, 1999 at 01:41:48PM +0100, Dag-Erling Smorgrav wrote: > [bringing this back to -current, with a Bcc to -security] > > "Kenneth D. Merry" <ken@kdm.org> writes: > > Jonathan Lemon wrote... > > > In article <local.mail.freebsd-current/199911042000.NAA91632@panzer.kdm.org> you write: > > > > Before I spend a lot of time hunting this down, I figured it might be worth > > > > asking -- is there any particular reason why TCP sockets may be getting > > > > stuck in the CLOSING state more often now? > > > Not sure. But here's a tcpdump trace of a socket that ends up in the > > > CLOSING state. (on the host ``cache''). > > > [...] > > > 1. the other end (folly) never acks the FIN. The packets at > > > timestamp .492154 and .492160 do not cover the FIN in the > > > sequence space. Yet the host `folly' closes the socket. > > This is weird, and probably deserves some investigation (at least if > cache and folly are on the same LAN; otherwise there's a non-zero > possibility of the ACK simply getting lost on the way) Good point. I'll try taking a tcpdump on both sides to see if the ACK is getting lost, or if it just isn't getting sent at all. > Note that the state transition diagram in RFC793 does not specify a > timeout for the CLOSING -> TIME_WAIT transition, so any faithful > implementation of RFC793 has this bug (but why doesn't this happen on > -STABLE, or on pre-August -CURRENT?) I'm not sure abuot that one. But I've just committed a fix to tcp_fsm.h, which will cause it to re-transmit a FIN in CLOSING state. The FIN was originally taken out by Garrett in rev 1.5, and restored by dg in rev 1.6. However, it was re-removed in 1.10 when Garrett made a large commit, presumably he hadn't taken it out of his local tree. It fixes the problem here (at least, I can't replicate the problem any more). I'm not sure if I'm fixing the symptoms rather than the actual problem then, though. NetBSD has the same fix in their tree as well. I'm pretty sure that I've seen this problem on -current going back as early as March as well. > This hints at a potential DoS vulnerability. Hack a TCP stack to never > acknowledge FIN segments, and blast away at your victim; chances are > he'll run out of mbufs before you run out of source ports (each source > port can only be used once in the attack). Give me a few hours and I > might be able to verify this vulnerability experimentally. Do let me know if this is the case. I was considering this last night, but was too tired to try an figure out how to generate a TCP stream that would ACK everything but the FIN. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991107080903.23572>