From owner-freebsd-security@FreeBSD.ORG Wed Apr 21 04:29:33 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 91F8816A4CE for ; Wed, 21 Apr 2004 04:29:33 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C9B443D45 for ; Wed, 21 Apr 2004 04:29:33 -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 i3LBTH7E046516; Wed, 21 Apr 2004 04:29:21 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200404211129.i3LBTH7E046516@gw.catspoiler.org> Date: Wed, 21 Apr 2004 04:29:17 -0700 (PDT) From: Don Lewis To: silby@silby.com In-Reply-To: <20040421014736.H1228@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 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: Wed, 21 Apr 2004 11:29:33 -0000 On 21 Apr, Mike Silbersack wrote: > > 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. I'd be concerned about the extra memory, especially in cases where we want to support very large numbers of connections. As far as amplification, step C has a gain of less than one, since packets are only transmitted if the incoming packet hits the window, and they will be the same or smaller in size than the incoming packets. I don't know if it would be valid to rate limit them ... If this is the only edge case that we have to worry about, we might be able change the test to: if (th->th_seq == tp->last_ack_sent || th->th_seq == tp->last_ack_sent + tp->rcv_wnd - 1) {