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

From: Ken Faiczak (kfaiczak_at_sandvine.com)
Date: 01/16/04

  • Next message: Benjamin von Mossner: "ste (IEEE 802.3u iface) problem" 
    To: "'freebsd-net@freebsd.org'" <freebsd-net@freebsd.org>
Date: Fri, 16 Jan 2004 11:26:11 -0500

    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
    _______________________________________________
    freebsd-net@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-net
    To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"

  • Next message: Benjamin von Mossner: "ste (IEEE 802.3u iface) problem"