From owner-freebsd-net@FreeBSD.ORG Mon Jan 3 18:02:30 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E0BA16A4CE for ; Mon, 3 Jan 2005 18:02:30 +0000 (GMT) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id 21DD543D5D for ; Mon, 3 Jan 2005 18:02:30 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id j03I2Tta023994; Mon, 3 Jan 2005 10:02:29 -0800 (PST) Received: from [10.1.1.245] (nfw2.codefab.com [199.103.21.225] (may be forged)) (authenticated bits=0)j03I2R7i003947; Mon, 3 Jan 2005 10:02:28 -0800 (PST) In-Reply-To: <20050103012325.A62262@odysseus.silby.com> References: <20050103012325.A62262@odysseus.silby.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Charles Swiger Date: Mon, 3 Jan 2005 13:02:26 -0500 To: Mike Silbersack X-Mailer: Apple Mail (2.619) cc: net@freebsd.org Subject: Re: Fixing "Slipping in the window" before 4.11-release X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2005 18:02:30 -0000 On Jan 3, 2005, at 2:31 AM, Mike Silbersack wrote: > For the life of me, I can't figure out why SYN packets (other than > delayed retransmissions of the original SYN) would ever show up once a > connection is in the ESTABLISHED state. So, I'm proposing the > attached patch, which simply ignores any packet with the SYN flag on > it while a connection is in the ESTABLISHED state. Are you relying on the IPID or the connection tuple of srcIP+srcPort+destIP+destPort to identify the SYN packet as being associated with an already established connection? I suppose that if the sending TCP stack has poor IPID sequence generation, maybe it could be reusing IPIDs and thus breaking the uniqueness assumption. > This means that SYN packets left of the window will no longer receive > an ACK, and SYN packets in the window will no longer reset the > connection. In all states other than ESTABLISHED, SYN packets are > handled as they were before, in case there's some edge case where that > could happen. This seems to be a reasonable improvement: the stack shouldn't be ACK'ing data outside of a valid connection window to begin with. > What are people's thoughts on this? I'm especially interested how > stateful firewalls like IPF or PF would handle such a situation. How > do they respond to unexpected SYN packets? Generally, each bare SYN packet is treated as a seperate new connection request, and they expect the destination TCP stack to handle any duplicate SYNs resulting from duplicated packets. -- -Chuck