From owner-freebsd-net@FreeBSD.ORG  Sat Apr 24 09:05:48 2004
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 4A2C416A4CF
	for <net@freebsd.org>; Sat, 24 Apr 2004 09:05:48 -0700 (PDT)
Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch
	[62.48.0.70])	by mx1.FreeBSD.org (Postfix) with ESMTP id 491B643D1D
	for <net@freebsd.org>; Sat, 24 Apr 2004 09:05:47 -0700 (PDT)
	(envelope-from andre@freebsd.org)
Received: (qmail 16574 invoked from network); 24 Apr 2004 16:05:46 -0000
Received: from unknown (HELO freebsd.org) ([62.48.0.54])
          (envelope-sender <andre@freebsd.org>)
          by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP
          for <evans.alan@sbcglobal.net>; 24 Apr 2004 16:05:46 -0000
Message-ID: <408A9059.B31E720A@freebsd.org>
Date: Sat, 24 Apr 2004 18:05:45 +0200
From: Andre Oppermann <andre@freebsd.org>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Alan Evans <evans.alan@sbcglobal.net>
References: <20040424154328.24028.qmail@web80105.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
cc: net@freebsd.org
Subject: Re: TCP vulnerability
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 24 Apr 2004 16:05:48 -0000

Alan Evans wrote:
> 
> I agree, but what's most important is to maintain
> backward compatibility. If one breaks it, it's a DoS
> is some sense. I also saw some postings on NetBSD
> which does ratelimiting of ACKs (in response to SYNs),
> and ACKs RST. IMHO, the latter is bogus - why ACK a
> RST? And, the former may impose an artificial limit
> of some sort.

Dunno about the rate limiting.  The ACK of the RST is recommended
in the paper you have referenced but only when sequence number of
the segment with the RST is not the next expected but within the
window.  Makes sense to reduce the chances of an successful blind
reset from 2^32/win to 2^32.  With large windows definitely a win
by an order of an magnitude.

-- 
Andre