3

If the data that are being encapsulated have the possibility of corruption while crossing over the wire, what is stopping the TCP checksum itself from being corrupted, and if it also can be corrupted, why is it considered reliable data transfer?

Improve this question

3 Answers 3

Reset to default
5

To strictly answer the questions:

  • Can the checksum itself be corrupted? Certainly, the noise sources have no idea whether they are corrupting data bits or checksum bits
  • What happens if only the checksum itself is corrupted? The calculated value by the receiver is certain to fail the match.
  • If checksum and data are corrupted, t(as given in the first answer) it's very unlikely to match.

While checksums in general have the characteristic that there are many messages which identical checksums (after all, we're going from perhaps 1Kbyte packet to 16 bits), many real life checksums have surprising good and bad properties. For example, IP checksum is guaranteed to detect all 1-bit errors; but fails to detect byte swaps. Real communications lines have certain errors much more common than others: much more common to get "all bits arrive as 0" for a short period for example, and "bytes are swapped" is more or less impossible.

For a deeper understanding

Hope that's helpful

Jonathan.

Improve this answer
3
  • Unlikely but not impossible. Is very possible with enough packets over time. If the data is vital. You may try two checksum with two different algos and salts to further minimize the corruption. It will not eliminate the possibility, but will make it more unlikely.
    – rxantos
    Commented Nov 30, 2020 at 18:41
  • Just to clarify what I meant: in a typical communications circuit, there is lots of hardware which could generate runs of spurious 0s, but there isn't any hardware (or firmware) which has a fault condition which would generate intermittent runs of byte-swapped data. (Yes, we could imagine one, but they don't exist in production equipment.) Of course it's possible that a given packet could be corrupted in a way which is happens to be the same as byte-swapped (0x1000 -> 0x0010 is only two bit errors), but that's not really the same thing.
    – jonathanjo
    Commented Dec 2, 2020 at 18:28
  • @rxantos NB: two checksums of different algorithms won't reduce any corruption (in fact increase the number of corrupted packets very slightly because they will be bigger by the size of the second checksum). But they would reduce the chance of undetected corruption, if chosen well. Not sure what you're referring to with "salts": these are error-detecting codes, not cryptographic hashes.
    – jonathanjo
    Commented Dec 2, 2020 at 18:35
2

If the TCP checksum is corrupted, then it will not match the TCP pseudo header and payload. There should only be one checksum that matches the pseudo header and payload, but there are multiple TCP pseudo header and payload combinations that will resolve to the same checksum. It is a one-way function.

There is no completely reliable way to communicate over a network. Even if a second copy of the payload is used as a checksum, it is possible that both copies get corrupted in exactly the same way. The odds of that are very low, but that greatly increases the number of bits sent, impacting the throughput.

What the checksum does is gives you a good chance that your data are not corrupt, and it is very small and quickly, easily calculated.

What TCP reliability really means is that the data are guaranteed to be delivered, and in order, to the application. This is accomplished by handshaking and acknowledgements. Contrast this to UDP, an unreliable protocol, that gives no such guarantee, not even that the data will reach the destination.

Improve this answer
1

what is stopping the TCP checksum itself from being corrupted,

Nothing.

and if it also can be corrupted, why is it considered reliable data transfer?

If either the checksum, the data or both are corrupted then most likely the checksum will not match and the packet will be discarded (and later retransmitted). However there is a possibility that the checksum will match dispite the corruption.

In general most networks rarely corrupt packets and the TCP checksum rejects most of those that do get corrupted, so the overall probability of delivering a corrupted packet so the application is acceptably low on most networks. However if you have a network that frequently corrupts packets and you transfer a large ammount of data then the TCP checksum starts to look sorely inadequate.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.