TCP Timestamping can be used to retrieve information about your system that you may not wish to be public. It turns out that TCP Timestamping is equal to the uptime (after a fashion) of many systems, and as such can give you extra information about the running system.

Credit:
The information has been provided by Bret McDanel.
The NMap port scanner includes the ability to scan hosts TCP timestamping and determining uptime information remotely.

What is Timestamping? How can it be used to gain information about a running system? Timestamping is a TCP option, which may be set, and if set takes 12 bytes in the header (for each packet) in addition to the 20 bytes a TCP header normally takes. This is exclusive of any other options. What good is this overhead? According to RFC1323:

"The timestamps are used for two distinct mechanisms: RTTM (Round Trip Time Measurement) and PAWS (Protect Against Wrapped Sequences).".

Anyone interested in TCP Timestamps should read RFC1323 (these are not the IP timestamping options). The fact that timestamping exists isn't anything special in itself, but how the value is populated and how the value is set is somewhat interesting.

4.4BSD increments the timestamp clock once every 500ms and this timestamp clock is reset to 0 on a reboot - TCP/IP ILLUS v1, p349.

The timestamp value to be sent in TSval is to be obtained from a (virtual) clock that we call the "timestamp clock". Its values must be at least approximately proportional to real time, in order to measure actual RTT. - RFC1323 May 1992

Note that the RFC does not dictate that the timestamp clock be tied to system uptime, so any system that doesn't conform to this is perfectly valid (i.e. Windows 2000). Additionally, the rate at which each system increments the clock need not be disclosed either, as the timestamp value is only echoed back to the sender for the sender to process.

This means that in 4.4BSD we can use this number to directly tell the time that a system has been up. All we have to do is make a connection and record the received timestamp. Not everyone implements timestamping this way however. This yields various results on different operating systems. Linux for instance increments every 1 ms, Cisco IOS increments every .1 ms. Windows 95/98/NT4 do not support Timestamping (although rumor has it that there is a patch to enable RFC1323 functionality on 95/98/NT4) Win2k does, but this value does not appear to be directly related to uptime.
This means that in order to tell the uptime we need to know what OS we are looking at, or at the very least make multiple connections and try to guess what the increment is based on elapsed time vs. increment.

There are some limitations to using this method for recording uptime. Certain systems have a maximum limit on how long their 'uptime' can be.
The timestamp is a 32-bit number (signed), and as such, it will overflow into the sign bit after 2147483647 ticks. Based on the number of ticks per second, you can easily determine when this will roll over.

One can also map out the number of systems in a load-balanced environment by connecting repeatedly to the group of machines, and inspecting the Timestamps. For each different time you have a different machine.

RFC1323 talks about the frequency the 'timestamp clock' should be updated. The receiver algorithm does place some requirements on the frequency of the timestamp clock.

(a) The timestamp clock must not be "too slow".

It must tick at least once for each 2**31 bytes sent. In
fact, in order to be useful to the sender for round trip
timing, the clock should tick at least once per window's
worth of data, and even with the RFC-1072 window
extension, 2**31 bytes must be at least two windows.

To make this more quantitative, any clock faster than 1
tick/sec will reject old duplicate segments for link
speeds of ~8 Gbps. A 1ms timestamp clock will work at
link speeds up to 8 Tbps (8*10**12) bps!

(b) The timestamp clock must not be "too fast".

Its recycling time must be greater than MSL seconds.
Since the clock (timestamp) is 32 bits and the worst-case
MSL is 255 seconds, the maximum acceptable clock frequency
is one tick every 59 ns.

However, it is desirable to establish a much longer
recycle period, in order to handle outdated timestamps on
idle connections (see Section 4.2.3), and to relax the MSL
requirement for preventing sequence number wrap-around.
With a 1 ms timestamp clock, the 32-bit timestamp will
wrap its sign bit in 24.8 days. Thus, it will reject old
duplicates on the same connection if MSL is 24.8 days or
less. This appears to be a very safe figure; an MSL of
24.8 days or longer can probably be assumed by the gateway
system without requiring precise MSL enforcement by the
TTL value in the IP layer.

Based upon these considerations, we choose a timestamp clock frequency in the range 1 ms to 1 sec per tick. This range also matches the requirements of the RTTM mechanism, which does not need much more resolution than the granularity of the retransmit timer, e.g., tens or hundreds of milliseconds.

As you can see all of these systems are within the RFC in their timings, however varied.

If you want to quickly get the Timestamp value, you can fire up tcpdump, and watch for it. Here is an example of what you may see and how to interpret the data:
> myhost.12345 > theirhost.22: . 1:1(0) ack 1 win 5840 (DF)

The timestamps are located near the end of the line, where the TCP Options are printed. The first timestamp is sent by 'myhost', the second is what 'theirhost' last sent us (we are expected to return that to them). The numbers are the number of ticks that have accumulated in the 'timestamp clock' and if the OS supports it, can reveal an uptime.

The information below was obtained by the author and several people running various OSs that were scanned and the results compared against the actual uptime.
If you are considering disabling timestamping on your system, please read RFC1323 for more information (especially if you are on a fast network).

Windows
Win2k sends the timestamp after the syn/ack handshake is complete (sends 0 TS during the 3-way handshake) and increment every 100ms initial random number.
95/98 does not support TS
NT 3.5/4 does not support TS

IRIX
5.3+ Support Timestamps
5.3-6.1
/var/sysgen/master.d/bsd contains the kernel variables. After editing you must use /etc/autoconfig and reboot
Under 6.5 edit /var/sysgen/mtune/bsd or use systune (like BSDs sysctl) tickrate 2/sec

HPUX
9.x No (9.05 and 9.07 have patches to support Timestamps)
To enable you must poke the kernel variable tcp_dont_tsecho to 0

10.00,01,10,20,30 Support Timestamps

11 Enabled by default

AIX
3.2 & 4.1 Support Timestamps
Tunable via the 'no' command

SunOS
4.1.4 No (May be purchased as a Sun Consulting Special)

Solaris
2.5 No (May be purchased as a Sun Consulting Special)
2.6 may be uptime but rolls over quickly, increments 1000 ticks/second
2.7 tickrate 100/sec (its not exactly uptime there was a 5 minute
skew on a 112 day uptime)
8 it is uptime, 100 ticks/second
To enable:
ndd /dev/tcp tcp_tstamp_always 1
If the parameter is set (non-zero), then the TCP timestamp option will always be negotiated during connection initiation. The scale option will always be used if the remote system sent a timestamp option during connection initiation. To use the timestamp, both hosts have to support RFC 1323.