From owner-freebsd-hackers Tue Sep 30 17:53:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA04971 for hackers-outgoing; Tue, 30 Sep 1997 17:53:20 -0700 (PDT) Received: from a42.deep-thought.org (A42.deep-thought.org [203.4.184.227]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA04966 for ; Tue, 30 Sep 1997 17:53:14 -0700 (PDT) Received: from a42.deep-thought.org ([127.0.0.1]) by a42.deep-thought.org with esmtp id m0xGD5O-0024w4C (Debian Smail-3.2 1996-Jul-4 #2); Wed, 1 Oct 1997 10:56:18 +1000 (EST) Message-Id: X-Mailer: exmh version 1.6.9 8/22/96 To: hackers@freebsd.org Subject: FreeBSD TCP stack SUX big juicy ones. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 01 Oct 1997 10:56:17 +1000 From: Richard Jones Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Well it seems the original subject for this email: "TCP connection initiation problem?" was not technical enough for the hackers@freebsd.org list and got lost amongst techno-gems such as "Our *NIX is better than their *NIX" and "The number of the beast is vi vi vi". Now as important as these issues are I was hoping I could get some feedback on the following situation: Could someone explain what lies behind the packet exchange shown below. 204.216.27.18 is FreeBSD's smtp port and port 8000 is a non-existent port on aaa.bbb.ccc.ddd (i.e. the initial packet from aaa.bbb.ccc.ddd to freebsd.org is forged). 20:42:56.116714 aaa.bbb.ccc.ddd.8000 > 204.216.27.18.25: S 667:667(0) win 4096 (ttl 200, id 666) 20:42:56.686714 204.216.27.18.25 > aaa.bbb.ccc.ddd.8000: S 856239105:856239105(0) ack 668 win 16384 (DF) (ttl 53, id 16513) 20:42:56.686714 aaa.bbb.ccc.ddd.8000 > 204.216.27.18.25: R 668:668(0) win 0 (ttl 255, id 5507) Now at this point SunOS, Linux and NetBSD all take no for an answer, but FreeBSD just won't quit. It takes FreeBSD another 1min15secs to decide its SYN's are not wanted (i.e the connection establishment timers kicks in). It should be noted that the initial packet can have its source faked and the packet exchange will occur between the FreeBSD host and the unsuspecting other. 20:43:02.266714 204.216.27.18.25 > aaa.bbb.ccc.ddd.8000: S 856239105:856239105(0) ack 668 win 16384 (DF) (ttl 53, id 16672) 20:43:02.266714 aaa.bbb.ccc.ddd.8000 > 204.216.27.18.25: R 668:668(0) win 0 (ttl 255, id 5508) 20:43:26.236714 204.216.27.18.25 > aaa.bbb.ccc.ddd.8000: S 856239105:856239105(0) ack 668 win 16384 (DF) (ttl 53, id 17083) 20:43:26.236714 aaa.bbb.ccc.ddd.8000 > 204.216.27.18.25: R 668:668(0) win 0 (ttl 255, id 5509) Ok, so in the next packet FreeBSD finally decides to give up: 20:44:11.236714 204.216.27.18.25 > aaa.bbb.ccc.ddd.8000: R 1:1(0) ack 1 win 16384 (DF) (ttl 53, id 18235) Note the RST's from aaa.bbb.ccc.ddd are not getting lost on the network, I've verified on another host that these packets get through (the timings really tell that story anyways). Is this broken SYN-Flood protection? Does it allow Evil others to cause a large exchange of data between a FreeBSD host and any other at just the cost of a single packet to Mrs/Mr Evil? Or am I completely missing the point? Does this exchange have a use which is beyond my ken? Richard Jones