forged tsecr giving -ve numbers in rtt calculation causing retran smit on next tick

[Ken Faiczak]

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 at sandvine.com