From owner-freebsd-net@FreeBSD.ORG Wed Jan 21 06:21:42 2004 Return-Path: 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 AB7D116A555 for ; Wed, 21 Jan 2004 06:21:41 -0800 (PST) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A7B143D55 for ; Wed, 21 Jan 2004 06:21:36 -0800 (PST) (envelope-from kfaiczak@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2657.72) id ; Wed, 21 Jan 2004 09:21:30 -0500 Message-ID: From: Ken Faiczak To: 'Mike Silbersack' , richard@wendland.org.uk Date: Wed, 21 Jan 2004 09:21:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" cc: freebsd-net@freebsd.org Subject: RE: forged tsecr giving -ve numbers in rtt calculation causing re tran X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2004 14:21:42 -0000 it is on 4.7 since that is what our product is using but the same code still exists in 5.2 (we're actively migrating our product there) We definitely are seeing incorrect Tsecr returned (ie not 0, but tsecr > ticks, thus the -ve result) The question was more that it could be a problem in general since the checks are in place to make sure its between the min and max but the results end up outside that range and the question of whether this could be used as some sort of DoS attack since it causes significant bandwidth utilization that would not otherwise occur. And then even if later in the connection it sends proper tsecr the smoothing causes it to go nowhere fast (from -450M). In our case hz = 2500 so the retransmit is -ve so it happens at the next tick which is 400us if the other side does not ack that fast.. Disabling 1323 is not what we want as these do happen, but are not that common and we want it on all other connections. > -----Original Message----- > From: Mike Silbersack [mailto:silby@silby.com] > Sent: Wednesday, January 21, 2004 3:50 AM > To: richard@wendland.org.uk > Cc: Ken Faiczak; freebsd-net@freebsd.org > Subject: Re: forged tsecr giving -ve numbers in rtt > calculation causing > retran > > > > On Tue, 20 Jan 2004, Richard Wendland wrote: > > > This does suggest Ken is seeing TSecr messed up in some > other way than > > simple zeroing. > > Or working from an old codebase... we'll have to wait for him > to respond > to find out. KEN! KEN! WHERE ARE YOOOOOO? > > > I'd expect this to be a pretty rare event, and perhaps my suggestion > > that the 64 sec TCPTV_REXMTMAX limit be implemented correctly is a > > good enough solution on its own for a rare event. It > should certainly > > avoid the insane -450000000 tp->t_rxtcur Ken has seen. > It's simple to > > implement, does what was probably originally intended, and > also protects > > from bizarre problems with non-timestamp option SRTT calculation. > > > > Full validation of TSecr would be nice, but perhaps excessive for > > something that should not happen. A 64 second RTO may > discourage such > > strangeness :) > > > > Richard > > I think that just ensuring proper capping of the timeout is > good enough, > the other timestamp issue I was referring to is how it (incorrectly) > scales with hz. I think I'll take a look at both of these > problems once I > catch up on other patches I have in the pipeline. > > Mike "Silby" Silbersack >