Date: Wed, 21 Jan 2004 09:21:29 -0500 From: Ken Faiczak <kfaiczak@sandvine.com> To: 'Mike Silbersack' <silby@silby.com>, richard@wendland.org.uk Cc: freebsd-net@freebsd.org Subject: RE: forged tsecr giving -ve numbers in rtt calculation causing re tran Message-ID: <FE045D4D9F7AED4CBFF1B3B813C85337028578C7@mail.sandvine.com>
next in thread | raw e-mail | index | archive | help
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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FE045D4D9F7AED4CBFF1B3B813C85337028578C7>