From owner-freebsd-security@FreeBSD.ORG  Fri Apr 23 03:41:47 2004
Return-Path: <owner-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 65FA116A4CE
	for <freebsd-security@FreeBSD.org>;
	Fri, 23 Apr 2004 03:41:47 -0700 (PDT)
Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 2333143D46
	for <freebsd-security@FreeBSD.org>;
	Fri, 23 Apr 2004 03:41:47 -0700 (PDT)
	(envelope-from truckman@FreeBSD.org)
Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2])
	by gw.catspoiler.org (8.12.9p2/8.12.9) with ESMTP id i3NAfR7E051507;
	Fri, 23 Apr 2004 03:41:31 -0700 (PDT)
	(envelope-from truckman@FreeBSD.org)
Message-Id: <200404231041.i3NAfR7E051507@gw.catspoiler.org>
Date: Fri, 23 Apr 2004 03:41:27 -0700 (PDT)
From: Don Lewis <truckman@FreeBSD.org>
To: silby@silby.com
In-Reply-To: <20040423040235.R703@odysseus.silby.com>
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]
	<freebsd-security.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-security>,
	<mailto:freebsd-security-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-security>
List-Post: <mailto:freebsd-security@freebsd.org>
List-Help: <mailto:freebsd-security-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-security>,
	<mailto:freebsd-security-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Apr 2004 10:41:47 -0000

On 23 Apr, Mike Silbersack wrote:
> 
> On Thu, 22 Apr 2004, jayanth wrote:
> 
>> 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
> 
> 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.