Date: Mon, 6 May 2002 18:09:09 -0400 (EDT) From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> To: net@freebsd.org Subject: Junior network hacker tasks... Message-ID: <200205062209.g46M99N8070646@khavrinen.lcs.mit.edu>
next in thread | raw e-mail | index | archive | help
Currently, FreeBSD's implementation of RFC 1323 uses the contents of the `ticks' variable verbatim in the TCP timestamp options that it generates. This is perhaps undesirable, in that it allows the system at the other end to determine how long the system has been up. (Current versions of `nmap' do this.) Also, there are ordered comparisons done throughout the TCP implementation which will break should `ticks' ever wrap around; with high values of `HZ' it is possible for (the 32-bit truncation of) `ticks' to wrap over even relatively small periods of time (e.g., five days for HZ=10000). The following would both be useful activities: 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.) 2) Examine the places where the TCP stack references `ticks' for other reasons, and determine whether TCP would fail to operate correctly should `ticks' wrap around. How likely are such failures? Would it help if `ticks' (and derived values) were stored in a wider data type? In some cases, the wrap-around interval is impossibly long with respect to other timeouts, so there is not necessarily a problem in all cases. -GAWollman 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?200205062209.g46M99N8070646>