From owner-freebsd-security@FreeBSD.ORG Thu Apr 22 02:05:03 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 3549C16A4CE for ; Thu, 22 Apr 2004 02:05:03 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id C438C43D39 for ; Thu, 22 Apr 2004 02:05:02 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 4909 invoked from network); 22 Apr 2004 09:05:01 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 22 Apr 2004 09:05:01 -0000 X-pair-Authenticated: 209.68.2.70 Date: Thu, 22 Apr 2004 04:16:03 -0500 (CDT) From: Mike Silbersack To: Darren Reed In-Reply-To: <200404220829.i3M8TpcB022690@caligula.anu.edu.au> Message-ID: <20040422041136.A21358@odysseus.silby.com> References: <200404220829.i3M8TpcB022690@caligula.anu.edu.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 09:05:03 -0000 On Thu, 22 Apr 2004, Darren Reed wrote: > > 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 ? Yep, that makes sense. It would be very simple to implement as well. :) > 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 I think that the third section of the draft covers this case when it talks about checking the sequence numbers in both directions for packets. Looks like we have a lot of testing to do. :| Mike "Silby" Silbersack