From owner-freebsd-security@FreeBSD.ORG Thu Apr 22 07:59:23 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 F0EA616A4CE; Thu, 22 Apr 2004 07:59:23 -0700 (PDT) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id C195C43D1F; Thu, 22 Apr 2004 07:59:23 -0700 (PDT) (envelope-from jayanth@yahoo-inc.com) Received: from milk.yahoo.com (milk.yahoo.com [216.145.52.137]) i3MEwv8Q069347; Thu, 22 Apr 2004 07:58:57 -0700 (PDT) Received: (from root@localhost) by milk.yahoo.com (8.12.9/8.12.9) id i3MEwvM1075896; Thu, 22 Apr 2004 07:58:57 -0700 (PDT) (envelope-from jayanth) Date: Thu, 22 Apr 2004 07:58:57 -0700 From: jayanth To: Don Lewis Message-ID: <20040422145857.GA75539@yahoo-inc.com> References: <20040421184539.H18583@odysseus.silby.com> <200404212331.i3LNVE7E047907@gw.catspoiler.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200404212331.i3LNVE7E047907@gw.catspoiler.org> User-Agent: Mutt/1.4.1i X-Mailman-Approved-At: Fri, 23 Apr 2004 02:29:10 -0700 cc: freebsd-security@FreeBSD.org cc: avalon@caligula.anu.edu.au cc: jayanth@yahoo-inc.com 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 14:59:24 -0000 Don Lewis (truckman@FreeBSD.org) wrote: > On 21 Apr, Mike Silbersack wrote: > > > > On Wed, 21 Apr 2004, Don Lewis wrote: > > > >> > 1. Accept all RSTs meeting the criteria you just listed above. > >> > >> At this step, it would be better if we used the window size that was > >> advertised it the last packet sent, since that is what the sequence > >> number of the RST packet will be calculated from, while the window size > >> could have increased if data was consumed from the receive queue between > >> the time we sent the last packet and when we received the RST. > >> > >> It doesn't look like we keep the necessary data for this. Probably the > >> easiest thing to do would be to calculate the expected sequence number > >> in tcp_output() and stash it in the pcb. > > > > Do you have access to a system that exhibits the "RST at end of window" > > syndrome so that you could code up and test out this part of the patch? > > Nope. The only report of this that I saw was from jayanth. Judging by > the tcpdump timestamps, it looks like whatever this wierd piece of > hardware was, it was nearby. > if i remember right this was done to handle the Alteons which generate a RST segment that would fall within the window size but not the next expected sequence no. So they would do something crazy like rcv_nxt + rcv_win as the sequence no, for the RST segment rather than rcv_nxt + 1. This was part of the RFC though. If it is a problem we can always revert it back. jayanth