Re: [LARTC] [OT]: rtt measurement using tcp timestamps from a MITM

[Arthur van Leeuwen <arthurvl@sci.kun.nl>]

On Fri, 28 Jun 2002, Patrick McHardy wrote:

> Hi Arthur,
>
> Arthur van Leeuwen wrote:
>
> >>A TCP usually takes care of this (wraparound after min. 24.8 days), but
> >>this will not be true anymore. if we choose our timestamp clock to
> >>increase once every 1 ms the sign bit will wrap after 5.5 minutes. I'm
> >>not sure what to do about this (this is why i'm writing), does anyone
> >>here have good ideas? I would also be happy about a completly different
> >>approach, somehing totaly passive would be nice .. :)
> >>
> >
> >The completely different approach would be to recognize all TCP streams
> >running through the machine and keep clocks for them: store the most recent
> >RTTM SYN time for a particular stream as well as the current time of the
> >machine when that RTTM time was seen. This will give you a good enough
> >approximation of the clock-skew between what you would put in the RTTM field
> >yourself and what is in there already, allowing you to use the RTTM fields
> >if they already exist. Note that this takes 64 bits, i.e. 8 bytes of storage
> >
> I hope i got you right, you mean i should calculate the difference
> between my clock and the first timestamp of a session, then
> send my own and on reply substract the clock-skew again ?

No, that is active intervention again. I meant to *remember* the value of
your clock and the last seen RTTM field for a session, and then when
the corresponding ack returns use that remembered value as opposed to the
the value in the RTTM field for your round-trip time calculation.

> >per TCP stream, and tracking of all active TCP streams running through your
> >machine.  However, the latter is probably necessary *anyway* if you are
> >going to do rate control, as you're bound to want to store the windowsizes
> >and stuff related to each TCP stream separately.

> Yes connection tracking is necessary (and already working fine :)

Well, what you do then is (in pseudocode):

    if packet contains RTTM field:
        if packet is SYN:
            remember local time (RTTM value, TCP stream)
            send packet on
        else:
            lookup local time for (TCP stream, RTTM value)
            calculate round-trip with local time
    else:
        do whatever you like

Thereby you merely use the value in the RTTM field as a key to a set of
stored local clockvalues. Yes, this will break if the value in the RTTM does
not monotonically increase, but... that increase *is* guaranteed by the RFC.

Doei, Arthur.

-- 
  /\    / |      arthurvl@sci.kun.nl      | Work like you don't need the money
 /__\  /  | A friend is someone with whom | Love like you have never been hurt
/    \/__ | you can dare to be yourself   | Dance like there's nobody watching

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/