Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 6 May 2002 17:26:20 -0500 (CDT)
From:      Mike Silbersack <silby@silby.com>
To:        Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
Cc:        net@freebsd.org
Subject:   Re: Junior network hacker tasks...
Message-ID:  <20020506171825.P60840-100000@patrocles.silby.com>
In-Reply-To: <200205062209.g46M99N8070646@khavrinen.lcs.mit.edu>

next in thread | previous in thread | raw e-mail | index | archive | help

On Mon, 6 May 2002, Garrett Wollman wrote:

> 1) Change the RFC 1323 implementation to use ticks relative to the
> time the socket was created.  This is fairly easy to do and requires
> changes to only a handful of lines of code.  (Keep in mind that only
> timestamps we send over the network ought to be so treated -- the
> timestamps stored in the TCPCB are a separate issue.)  For additional
> confusion value, consider adding a random bias when each connection is
> created.  (TCP already bogusly depends on a maximum segment lifetime
> of 30 seconds, so segments dallying in the network for days are
> probably not a concern.  The correct answer for the user who has set
> HZ to 1000000 is ``don't do that, then'' -- but this probably ought to
> be documented as a limitation.)

Is doing this wise?  I have this nagging feeling that randomizing (or
zeroing on each new connection) the timestamp would degrade its usefulness
for PAWS checks and the like.  (Don't ask me how, I haven't thought it
through fully.)

How about this idea:

- For inbound connections, use 0 as the start value for the timestamp, as
you suggest above.

- For outbound connections, generate the timestamp offset using a hash
similar to the one used for ISN generation.  This way, timestamps won't
jump around when connections are broken and reestablished / etc.  This is
a slight information leak; one can tell that the machine hasn't been
rebooted.  However, you would have to poll the machine quite often to
figure out what the uptime really is.

I think that the solution to wrapround with "ticks" is to normalize the
value using hz to some known amount.

I could certainly code these changes up (I've been thinking along the same
lines for a while), but I'd be more than happy to defer to some unknown
lurker on the mailing list who wants to make a name for his/her self. :)

Mike "Silby" Silbersack


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message




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