One of the less obvious and hence less popular ways to detect packet rewriting devices and learn more about network configuration is analyzing the maximum segment size field in incoming traffic.
Because IP packet fragmentation adds noticeable overhead to the fragmented traffic, it is often perceived as a performance nightmare, and many implementers try to prevent it. On the other hand, as discussed earlier, fragmentation is difficult to eliminate, as it seems to be nearly impossible to accurately, quickly, and reliably determine the maximum transmission unit (MTU) over a path in advance of actual communications. Even the best method available, path MTU discovery, is far from perfect and still impacts performance when triggered. In order for it to detect the correct MTU setting by trial and error, some packets that do not fit might have to be discarded and be resent.
To prevent the performance and reliability impact of path MTU discovery and reduce the overhead of fragmentation, many NAT firewalls that rewrite certain parameters of outgoing traffic also change the declared Maximum Segment Size (MSS) parameter in TCP headers on connections originating from the private network to one more suitable for the external link from the network. This new setting is likely to be slightly narrower (have a lower MTU) than that of the LAN. This modification ensures that the receiving party does not attempt to send data that would not fit over the link if that link is across the particular part of the infrastructure with the lowest MTU, thus making fragmentation less likely to occur. (This assumes that any MTU incompatibility is most likely to occur near the sender or recipient system on the so-called last mile, where various types of low MTU links, such as DSL connections or wireless lines, are often found, and packets might need to be “downsized” to fit through those pipes.)
This reduction in the MSS alone is not particularly easy to detect. In fact, it is impossible to tell whether the MSS was set to a given value by the sender or modified somewhere down the road. That is, except for one minor thing. Recall from Chapter 9 that there is something special about the window size selection algorithm on many of today’s systems:
The window size setting determines the amount of data that can be sent without acknowledgment. The specific setting is often chosen according to the developer’s personal voodoo rules and other religious beliefs. The two most popular approaches say the value should be either a multiple of the MTU minus protocol headers (a value referred to as Maximum Segment Size, or MSS) or simply something sufficiently high and “round.” Older versions of Linux (2.0) used values that were powers of 2 (for example, 16,384). Linux 2.2 switched to a multiple of MSS (11 or 22 times MSS, for some reason), and newer versions of Linux commonly use 2 to 4 times MSS. The Sega Dreamcast, a network-enabled console, uses a value of 4,096, and Windows often uses 6,4512.
An ever-increasing number of today’s systems (including newer versions of Linux and Solaris, certain versions of Windows, and SCO UnixWare) uses a window size setting that is a multiple of the MSS. Thus, it’s easy to tell when the MSS setting in a packet has been tampered with because the window size on the resulting packet will no longer be a specific multiple of MSS. In fact, it’s likely that it will no longer divide by MSS at all.
By comparing the MSS to window size, you can reliably detect the presence of a group of firewalls that support MSS clamping (readjusting to match the link) on a variety of systems. Although clamping is optional on Linux and FreeBSD, it is often performed automatically on home firewalls and on smart DSL routers or other home networks. Hence, the presence of an anomalous MSS setting indicates not only a packet-rewriting device, but an association also with NAT capability, which can be taken as an indicator of the sender’s network connection.