From owner-freebsd-security@FreeBSD.ORG Tue Jul 5 20:35:37 2005 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E667016A41C for ; Tue, 5 Jul 2005 20:35:37 +0000 (GMT) (envelope-from wollman@khavrinen.csail.mit.edu) Received: from khavrinen.csail.mit.edu (khavrinen.csail.mit.edu [128.30.28.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8CFE843D48 for ; Tue, 5 Jul 2005 20:35:37 +0000 (GMT) (envelope-from wollman@khavrinen.csail.mit.edu) Received: from khavrinen.csail.mit.edu (localhost.csail.mit.edu [127.0.0.1]) by khavrinen.csail.mit.edu (8.13.1/8.13.1) with ESMTP id j65KZT6Y087553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK CN=khavrinen.lcs.mit.edu issuer=SSL+20Client+20CA); Tue, 5 Jul 2005 16:35:30 -0400 (EDT) (envelope-from wollman@khavrinen.csail.mit.edu) Received: (from wollman@localhost) by khavrinen.csail.mit.edu (8.13.1/8.13.1/Submit) id j65KZTwM087550; Tue, 5 Jul 2005 16:35:29 -0400 (EDT) (envelope-from wollman) From: Garrett Wollman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17098.61201.244682.110397@khavrinen.csail.mit.edu> Date: Tue, 5 Jul 2005 16:35:29 -0400 To: Darren Reed In-Reply-To: <200507051428.j65ESjJu001522@caligula.anu.edu.au> References: <17096.38921.588487.576918@khavrinen.csail.mit.edu> <200507051428.j65ESjJu001522@caligula.anu.edu.au> X-Mailer: VM 7.17 under 21.4 (patch 17) "Jumbo Shrimp" XEmacs Lucid X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-1.6 (khavrinen.csail.mit.edu [127.0.0.1]); Tue, 05 Jul 2005 16:35:30 -0400 (EDT) X-Virus-Scanned: ClamAV 0.85.1/967/Mon Jul 4 17:36:05 2005 on khavrinen.csail.mit.edu X-Virus-Status: Clean X-Spam-Status: No, score=0.6 required=5.0 tests=J_CHICKENPOX_33 version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on khavrinen.csail.mit.edu X-Mailman-Approved-At: Wed, 06 Jul 2005 12:49:10 +0000 Cc: freebsd-security@freebsd.org Subject: Re: packets with syn/fin vs pf_norm.c X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2005 20:35:38 -0000 < said: > No, you're wrong on this. > Packets for TCP with SYN + FIN set are valid under T/TCP. Packets for TCP with SYN + FIN set are valid under TCP, period. See RFC 793 page 66, where it describes the processing of segments with the SYN bit set: The connection state should be changed to SYN-RECEIVED. Note that any other incoming control or data (combined with SYN) will be processed in the SYN-RECEIVED state, but processing of SYN and ACK should not be repeated. Later, on page 75, the spec discusses the handling of FIN bits: eighth, check the FIN bit, Do not process the FIN if the state is CLOSED, LISTEN or SYN-SENT since the SEG.SEQ cannot be validated; drop the segment and return. [We are in SYN-RECEIVED at this point so this graf does not apply.] If the FIN bit is set, signal the user "connection closing" and return any pending RECEIVEs with same message, advance RCV.NXT over the FIN, and send an acknowledgment for the FIN. Note that FIN implies PUSH for any segment text not yet delivered to the user. SYN-RECEIVED STATE ESTABLISHED STATE Enter the CLOSE-WAIT state. See also section 3.4 on page 30. The only thing that RFC 1644 adds to this is the ability to short-circuit the three-way handshake by means of persistent sequence numbers. In short, SYN+FIN segments are legitimate *whether or not* one is using T/TCP (and one should not be at this point in time, as the T/TCP protocol is known to be flawed). Note that the specification does not require a receiver-TCP to buffer data (including the FIN bit) received on SYN, and FreeBSD in the current implementation does not do so unless RFC 1644 is in use. What PF is doing is not obviously wrong, since it is what FreeBSD's TCP would normally do anyway. -GAWollman