Probabilistic remote traffic estimation based on IP/ID variation
A lot of work has been done using IP/ID variation, but this particular field of the Internet Protocol remains very interesting. We present in this paper our research on remote traffic estimation based on IP/ID variation and how it can be used by attackers or competitors.A lot of work has been done using IP/ID variation, but this particular field of the Internet Protocol remains very interesting. We present in this paper our research on remote traffic estimation based on IP/ID variation and how it can be used by attackers or competitors.
Introduction
Identification field of the Internet Protocol (commonly called IP and defined in RFC 791) is a 16 bits field originally incremented on every packet sent by the host. Nowadays, this behavior heavily depends on the operating system installed on the host. Active network devices between the target host and the examiner host can also alter this behavior, thus making difficult to obtain valuable results.
However, identification field is still used in a wide variety of servers all around the Internet and therefore can be used to determine information on a server’s traffic and load. This is particularly true for server with a very low traffic but not for heavy servers handling a large amount of packets a day. A common approach when trying to evaluate the amount of traffic a server handles consists of measuring the IP/ID variation in a short amount of time and computing the outgoing packet rate based on this measure.
The examiner host sends at least two probes toward the target server and waits for answers. Once received, these answers are dissected and the IP/ID variation is computed allowing the examiner host to compute the outgoing packet rate (number of packets sent by second). But the round-trip time is not taken in account in this computation and the final packet rate is biased. The faster the measure is taken, the bigger the error is.
ICMP timestamps to get a more precise result
In order to get a more precise measure, ICMP timestamp requests can be sent to the target server (if this one supports this type of requests, this is generally not the case). ICMP timestamps are defined in RFC 792 as «32 bits of milliseconds since midnight UT». An ICMP Timestamp response contains three fields: the originate timestamp (which is set by the sender), the receive timestamp (corresponding to the exact reception time) and the transmit timestamp (set by the receiver).
From this, one can easily compute a precise round-trip time, and know exactly when an ICMP response was sent by a remote host.
The idea behind this use of ICMP timestamp is to get a precise measure of when the remote server has sent an answer and therefore be able to compute more precisely its outgoing packet rate. We developed a command-line utility that implements this better approach. But two problem remain. First, this approach is valid only for servers that do not handle a huge amount of packets. Second, the examiner host constantly sends a lot of ICMP packets and can be detected as intrusive. By sending less ICMP packets, say one packet per ten seconds, this tool will be quite stealth but will produce a non-reliable result. A better approach is required.
Probabilistic approach based on IP/ID prediction
We tried another approach, based on a statistical analysis. Our predicate was the following: A: « If a server S handles a variable but significant amount of traffic, the measured IP/ID variation will be near random.» Given an error delta, the probability that we will be able to predict the next IP/ID value is of: P(A,D) = D/N with D the error delta and N=65536. If the server has no traffic at all, P(A) with an error delta of 1 will be highly probable. If the server handles a huge amount of traffic, P(A) will be near of 1 if D is near to N. If we try to predict the N+1 IP/ID value based on its previous variation, and if we increase D every time our prediction is wrong, we will be able to compute an approximation of this probability and therefore be able to quantify the amount of traffic handled by the remote server. Another approach consists in measuring the average bias D between X measures and to compute D/N.
We developed a specific tool that implements this approach and allows a remote traffic comparison between two given hosts. This tool is based on the above technique and tries to evaluate the average bias in order to quantify each remote server’s traffic. This tool has been developed in Python, and is based on the wonderful Scapy Python library [1]. We made some tests against some well known servers, and got some interesting results: (66.220.149.32 is a server belonging to Facebook whereas 199.59.148.10 is a server belonging to Twitter).
Conclusion
This technique and tool can be very useful to determine if a competitor’s traffic is higher or lower than a given traffic without being easily detected. Furthermore, this technique can be useful to detect a denial of service attempt (huge amount of traffic against one or many servers).
Damien Cauquil