Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 16 Jan 2004 11:26:11 -0500
From:      Ken Faiczak <kfaiczak@sandvine.com>
To:        "'freebsd-net@freebsd.org'" <freebsd-net@freebsd.org>
Subject:   forged tsecr giving -ve numbers in rtt calculation causing retran smit on next tick
Message-ID:  <FE045D4D9F7AED4CBFF1B3B813C85337028578AB@mail.sandvine.com>

next in thread | raw e-mail | index | archive | help
We have an application that periodically sees
the tp->t_rxtcur go to a large -ve number

it seems there is no protection from TCP session
mucking up the tsecr values

tcp_input() receives it and does (ticks - tsecr + 1)

in some cases this ends up as say -450000000
because the secr has been forged.

it then does an unsigned max(tp->t_rttmin, rtt + 2) fn 
rtt is -ve but the unsigned max returns it anyway

then the TCPT_RANGESET() does the min/max compare as unsigned as well
but the min is the large -ve number which becomes a large +ve number
and the number is < this so rxtcur = the large unsigned +ve number
    but since rxtcur is signed its now -ve and the retransmit timer
    pops at the next tick.


options to protect against this
1. use imax() in tcp_xmit_timer
	this has the effect whrn this happens of setting the 
      rxtcur to the max all the time
2. after process_ACK:
     where it checks the TOF_TS
     it check if tsecr == 0 and ignores it
     we could also ignore cases where (ticks - tsecr) < 0
     - though I'm unsure what happens here in the case where ticks rolls
over
       I think it would just ignore the update that time and use the 
       t_rttime calcualtion.

any thoughts??

Ken Faiczak
kfaiczak@sandvine.com



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FE045D4D9F7AED4CBFF1B3B813C85337028578AB>