From owner-freebsd-security@FreeBSD.ORG  Tue Apr 20 23:44:51 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 5896016A4CF
	for <freebsd-security@FreeBSD.org>;
	Tue, 20 Apr 2004 23:44:51 -0700 (PDT)
Received: from relay.pair.com (relay.pair.com [209.68.1.20])
	by mx1.FreeBSD.org (Postfix) with SMTP id C2FFB43D5C
	for <freebsd-security@FreeBSD.org>;
	Tue, 20 Apr 2004 23:44:48 -0700 (PDT)	(envelope-from silby@silby.com)
Received: (qmail 68753 invoked from network); 21 Apr 2004 06:44:47 -0000
Received: from niwun.pair.com (HELO localhost) (209.68.2.70)
  by relay.pair.com with SMTP; 21 Apr 2004 06:44:47 -0000
X-pair-Authenticated: 209.68.2.70
Date: Wed, 21 Apr 2004 01:50:28 -0500 (CDT)
From: Mike Silbersack <silby@silby.com>
To: Don Lewis <truckman@FreeBSD.org>
In-Reply-To: <200404210346.i3L3ki7E045504@gw.catspoiler.org>
Message-ID: <20040421014736.H1228@odysseus.silby.com>
References: <200404210346.i3L3ki7E045504@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
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: Wed, 21 Apr 2004 06:44:51 -0000


On Tue, 20 Apr 2004, Don Lewis wrote:

> I am concerned that step C will not solve the compatibility problem. The
> FreeBSD host is sending a FIN to close an established connection, and
> the peer host adding the window size advertised in the FIN packet to the
> sequence number acknowledged in the FIN packet, and using the sum as the
> sequence number for the RST packet, which puts the sequence number at
> the end of the receive window.

Would it be feasible for us to create a four to five element array to
track "resettable" sequence numbers?  This could hold the sequence numbers
of the last few packets transmitted, and account for that edge case as
well.  I'm very uneasy with the IETF step C - sending more packets out
into the network sounds like a new type of amplification attack.

Mike "Silby" Silbersack