From owner-freebsd-security@FreeBSD.ORG Fri Apr 23 16:10:02 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 614D616A4CE for ; Fri, 23 Apr 2004 16:10:02 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id CCFC543D1D for ; Fri, 23 Apr 2004 16:10:01 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 58921 invoked from network); 23 Apr 2004 23:10:00 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 23 Apr 2004 23:10:00 -0000 X-pair-Authenticated: 209.68.2.70 Date: Fri, 23 Apr 2004 18:32:06 -0500 (CDT) From: Mike Silbersack To: Don Lewis In-Reply-To: <200404231041.i3NAfR7E051507@gw.catspoiler.org> Message-ID: <20040423182801.G5436@odysseus.silby.com> References: <200404231041.i3NAfR7E051507@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: Fri, 23 Apr 2004 23:10:02 -0000 On Fri, 23 Apr 2004, Don Lewis wrote: > > What type of packet was causing the Alteons to emit the RST? SYN, FIN, > > normal data? > > > > Also, has Alteon fixed the problem or do their load balancers still > > exhibit the behavior? > > The link I posted showed it was a FIN, and after the RST was sent (and > ignored by the FreeBSD stack because of the strict sequence number > check), the Alteon (or whatever it was) did not respond to the > retransmissions of the FIN packet. > > Maybe we can get by with the strict check by default and add a sysctl to > revert to the permissive check. I think Darren's suggestion would be a reasonable compromise; use the strict check in the ESTABLISHED state, and the permissive check otherwise. Established connections are what would be attacked, so we need the security there, but the closing states are where oddities seem to pop up, so we can use the permissive check there. If this is acceptable, I'd like to get it committed this weekend so that we can still get it into 4.10. Mike "Silby" Silbersack