From owner-freebsd-security@FreeBSD.ORG  Fri Apr 23 01:57:15 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 5ABFB16A4CE
	for <freebsd-security@FreeBSD.org>;
	Fri, 23 Apr 2004 01:57:15 -0700 (PDT)
Received: from relay.pair.com (relay.pair.com [209.68.1.20])
	by mx1.FreeBSD.org (Postfix) with SMTP id 722AA43D48
	for <freebsd-security@FreeBSD.org>;
	Fri, 23 Apr 2004 01:57:14 -0700 (PDT)	(envelope-from silby@silby.com)
Received: (qmail 40647 invoked from network); 23 Apr 2004 08:57:13 -0000
Received: from niwun.pair.com (HELO localhost) (209.68.2.70)
  by relay.pair.com with SMTP; 23 Apr 2004 08:57:13 -0000
X-pair-Authenticated: 209.68.2.70
Date: Fri, 23 Apr 2004 04:04:10 -0500 (CDT)
From: Mike Silbersack <silby@silby.com>
To: jayanth <jayanth@yahoo-inc.com>
In-Reply-To: <20040422145857.GA75539@yahoo-inc.com>
Message-ID: <20040423040235.R703@odysseus.silby.com>
References: <20040421184539.H18583@odysseus.silby.com>
	<20040422145857.GA75539@yahoo-inc.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
cc: freebsd-security@FreeBSD.org
cc: Don Lewis <truckman@FreeBSD.org>
cc: avalon@caligula.anu.edu.au
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 08:57:15 -0000


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?

Mike "Silby" Silbersack