Can a TCP checksum fail to detect an error? If yes, how is this dealt with?
If a TCP payload gets corrupted in transit the recomputed checksum won't match the transmitted checksum. Great, all fine so far.
If a TCP checksum gets corrupted in transit the recomputed checksum won't match the now corrupted checksum. Great, all fine so far.
What happens when both the payload and checksum get corrupted and the recomputed checksum, whilst different to what it should be, just happens to match the now corrupted checksum?
I can see with a good checksum algorithm (and additional checksums at lower levels) this might be very, very unlikely but isn't TCP meant to be 100% reliable? How does it resolve these false positives?
Answer
Something that should be noted here, and that most people overlook completely, is the fact, that the TCP checksum is actually a very poor checksum.
The TCP checksum is a 16-bit ones-complement sum of the data. This sum will catch any burst error of 15 bits or less, and all 16-bit burst errors except for those which replace one 1’s complement zero with another (i.e., 16 adjacent 1 bits replaced by 16 zero bits, or vice-versa). Over uniformly distributed data, it is expected to detect other types of errors at a rate proportional to 1 in 2^16. The checksum also has a major limitation: the sum of a set of 16-bit values is the same, regardless of the order in which the values appear.
Source: ftp://ftp.cis.upenn.edu/pub/mbgreen/papers/ton98.pdf
So if you randomly flip any number bits anywhere in the data part of the packet, the chances are 1 to 65536 that this error is not detected, even if you don't touch the checksum at all, as the new data, even though totally corrupt, has in fact the same checksum as the old one. If you just swap two 16 bit values in the data part, regardless which ones and regardless how often, the chances are even 100% that this error is not detected, since the order in which the 16 bit values appear in the data part of the packet is totally irrelevant to the value of the calculated checksum.
What I'm trying to say here is that you don't have to worry too much about the rather unlikely case that data and checksum both get corrupted and this error is not detected because the corrupted checksum matches the corrupted data, the truth is that every day millions of TCP packets on the Internet have only the data corrupted and this error is not detected because the uncorrupted checksum still matches the corrupted data.
If you need to transfer data and you want to be sure the data didn't get corrupted, the TCP checksum alone is certainly not enough for this task. I would even dare to say that a CRC checksum is not enough for this task, since a CRC32 may not detect an error where more than 32 bits in a row are affected (these errors can "cancel out" each other). The minimum checksum you'd need for ensuring flawless data transfer is the MD5 value of the data. Of course anything better than that (SHA-1, SHA-256, SHA-384, SHA-512, Whirlpool, and so on) will work even better, yet MD5 is sufficient. MD5 may not be secure enough for cryptographic security any longer (since it has been broken multiple times in the past), but as a data checksum MD5 is still absolutely sufficient.