Also, there's a kernel option: # RANDOM_IP_ID causes the ID field in IP packets to be randomized # instead of incremented by 1 with each packet generated. This # option closes a minor information leak which allows remote # observers to determine the rate of packet generation on the # machine by watching the counter. options RANDOM_IP_ID
On Monday 06 May 2002 22:09, you wrote: > 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 [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
