From owner-freebsd-security@FreeBSD.ORG Thu Apr 22 01:29:53 2004 Return-Path: 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 4D08416A4CE for ; Thu, 22 Apr 2004 01:29:53 -0700 (PDT) Received: from caligula.anu.edu.au (caligula.anu.edu.au [150.203.224.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id B1A4A43D49 for ; Thu, 22 Apr 2004 01:29:52 -0700 (PDT) (envelope-from avalon@caligula.anu.edu.au) Received: from caligula.anu.edu.au (localhost [127.0.0.1]) by caligula.anu.edu.au (8.12.9/8.12.9) with ESMTP id i3M8TpbF022692; Thu, 22 Apr 2004 18:29:51 +1000 (EST) Received: (from avalon@localhost) by caligula.anu.edu.au (8.12.9/8.12.8/Submit) id i3M8TpcB022690; Thu, 22 Apr 2004 18:29:51 +1000 (EST) From: Darren Reed Message-Id: <200404220829.i3M8TpcB022690@caligula.anu.edu.au> To: silby@silby.com (Mike Silbersack) Date: Thu, 22 Apr 2004 18:29:51 +1000 (Australia/ACT) In-Reply-To: <20040422031525.E19921@odysseus.silby.com> from "Mike Silbersack" at Apr 22, 2004 03:16:12 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-security@freebsd.org Subject: Re: [Full-Disclosure] IETF Draft - Fix for TCP vulnerability (fwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2004 08:29:53 -0000 In some mail from Mike Silbersack, sie said: > On Thu, 22 Apr 2004, Darren Reed wrote: > > > 1. RSTs exactly at last_ack_sent (always accepted) > > > > To pursue this thought further, if a FIN has been sent or received > > (connection has migrated from ESTABLISHED to CLOSE_WAIT or something > > else) then receiving an RST at this point should be much less of a > > problem, yes ? > > > > The only drawback is I've seen sessions where there's a last ditch > > attempt to get data through even though a FIN has been received. > > > > Darren > > Are you suggesting that we use the strict check during the ESTABLISHED > phase, and the window-wide check during all other phases? Possibly :) I don't think it is important for session setup, but at the end of a session, you generally want it to disappear from your connection table sooner rather than later, right ? Furthermore, you're more likely to get a RST after a FIN has been sent, by either party, if you send another ACK because the other guy has decided to remove the socket already. Does this make sense ? Although this makes me wonder, what's the implication here for FIN packets - is there none ? The draft refers to SYNs (which do get special treatment) and RSTs (just more violent FIN packets.) If someone injects a FIN packet the way they would have done a RST, what are the implications ? Does a packet storm ensue ? Does the FIN get ignored ? Do FIN packets also need to be challenge-responsed now ? Darren