originated from the same host. What are the chances that three different source IPs sending traffic to our network had a probable (uncrafted) initial TTL of 255 and each was 9 hop counts away and they all had an interest in the same IP address at approximately the same time? Using the –vv option of TCPdump can give us two additional fields of display that can assist in determining if suspicious traffic has been spoofed.

When this traffic was detected on the network, traceroutes were executed back to the alleged source IPs in an attempt to determine if they were real or spoofed source IPs. Here are the

results of the traceroutes: traceroute somewhere.de

This example of using traceroutes isn't very conclusive. Each of the three different source IPs had approximately 12 or 13 hops back from the network upon which the sensor sniffed the packets. However, it does offer an example of the mechanics used to attempt to validate the authenticity of the source IP.

The hop count back from the traceroute is believably close to the expected hop count. Yet, using the IP identification values in conjunction with these results, these source IPs probably were spoofed. A hop count back to the source IP that varies widely from the expected hop count is a better indication that the source IP was spoofed. Also, if the actual hop counts back to the three different source IPs differed more substantially from each other, this too would be a better indicator of spoofing.

There are a couple of caveats associated with using traceroute for forensics. First, you might be unable to do traceroutes to/from your network because of router/firewall blocks of ICMP traffic, specifically "time exceeded in-transit" and "port unreachable" messages. Second, note that traceroute to a real IP might not be desirable because it can potentially illuminate your interest

in a site.

IP Checksums

Checksums are used to ensure that data has not gotten corrupted from source to destination. The algorithm used for TCP/IP is to divide the data that is being checksummed into 16-bit fields. Each 16-bit field has a 1's complement operation done on it and all of these 1's complement values are added. The final value is considered to be the checksum.

The IP checksum is found in the 10th and 11th bytes offset of the IP header. The IP checksum covers all fields in the IP header only. This checksum is different than the checksums that are computed for the embedded protocol fields because it is validated along the path from source to destination. Embedded protocol checksums such as TCP, UDP, and ICMP are validated by the destination host only. The IP checksum is validated by each router through which it passes from source to destination and finally is validated by the destination host as well.

If the computed checksum does not agree with the one found in the datagram, the datagram is discarded silently. No attempt is made to inform the source host of a problem. The idea is that

higher-level protocols or applications will detect this and deal with it.

The formula for the IP header checksum is used for all other embedded checksums as well. First, we divide the IP header into 16-bit fields. Because the IP header length is always a multiple of 4 bytes, we do not have to worry about extra fields that do not fall on 16-bit boundaries.

After all of the fields are separated, we take the 1's complement of each. This operation simply flips the bit. All of these individual 1's complement values are added to form the checksum. For example:

In the previous output, you see the first 16 bits of a very common beginning to an IP header. Each hex value is represented in four binary bits and each of these bits is flipped. This becomes the 1's complement value. This operation is commutative so you can add the hex values of the 16-bit fields and then take the 1's complement and the resulting checksum should be the same. The IP checksum is examined and recomputed for each hop on the way from source to destination. Intermediate routers validate the IP checksum, and if it is correct, the TTL value is decremented by 1. The IP header checksum must be recomputed to reflect this change in the IP header. Remember that this checksum validates the fields in the IP header only, not the rest of the datagram that consists of the embedded protocol header and data.

The rationale for checking the IP checksum for each hop makes sense when you think about it. The worst-case scenario is that the destination IP becomes corrupted. It makes no sense to forward a packet that has been corrupted because the corruption might alter the intent of the packet.

Although the IP checksum and all other checksums found in the datagram find most packet corruption, there is a problem. It is possible for entire 16-bit fields to be swapped and yet the

checksum will remain the same.

4500 003c

Look at the previous output. We swap the first two 16-bit fields (4500 003c) in the IP header.

The computed checksum for the correct sequence of these 16-bit fields is 1011 1010 1100 0010 (this doesn't include the high-order bit carryover). But, if we reverse the fields and compute the checksum, it is exactly the same. A datagram with 16-bit fields swapped is a vastly different datagram in meaning and resolution when fields are swapped. So, this is obviously a drawback of using this computation.

Why not use a more complicated and reliable algorithm for the checksum? This computation is done for each packet that a router receives. The simpler the algorithm, the quicker the computation time. The checksum algorithm is a fast and mostly reliable algorithm, and the clean swap of 16-bit fields is a rare occurrence. To read more about IP checksums, look at RFC 1071.