Is it redundant to add an extra checksum or CRC in TCP payload to make it possible for the receiver verify whether the data is same with the sent one?

Question

As TCP contains a checksum, and the TCP/IP stack will detect broken packets, is it redundant to add an extra checksum or CRC in a TCP payload (I mean the user data which could be read out by the socket api on the remote end), to make it possible for the receiver verify whether the data is same with the sent one?

Some thought about this question:

It's very common seen that there is a SHA256 value to verify the consistency when downloading files from internet.
The checksum contained in TCP packets already could detect broken packets in most cases.
The Modbus protocol for TCP dropped the CRC, which is used by the Modbus protocol for serial because there is already a checksum in TCP packets.

So, I am really confused now. Could somebody shed some light on this question?

I have googled, it's really not a new question, but the answer is still not clear, there are two opposite voices about this question.

For details, see these:

CRC checking done automatically on Tcp/Ip?

Is it possible for packets sent using TCP to ever arrive with different data?

ADDED:

The two questions aforementioned have been there for more than ten years! But there are still two opposite voices.

@PresidentJamesK.Polk There are two hashes for TCP/IP. For TCP layer, it's a 16 bits checksum(just add them up). — John, Jun 20 '21 at 03:11
I’m voting to close this question because it is a [cross-posting to serverfault.com](https://serverfault.com/questions/1066974/is-it-redundant-to-add-an-extra-checksum-or-crc-in-tcp-packets-to-make-it-possib) and was already answered there two days ago. If you don't like the answer (which got several upvotes) don't just cross-post exactly the same question somewhere else (and even failing to properly copy it, so that the included links to other questions don't show up as links any more). — Steffen Ullrich, Jun 20 '21 at 03:58
@Steffen Ullrich It was posted by myself on serverfault indeed two days ago. ***But*** there are much fewer users on serverfault. And this question **needs** and **deserves** more discussion. You see, the two questions aforementioned have been there for more than ten years. But there are still two opposite voices. — John, Jun 20 '21 at 04:39
@John: Conflicting answers don't go away by adding yet another answer :) But anyway, I've tried to summarize the issue. — Steffen Ullrich, Jun 20 '21 at 05:29

score 1 · Accepted Answer · edited Jun 20 '21 at 20:49

TCP has a checksum, which provides only some protection, simply because the checksum is only 16bit. For how much robustness the TCP checksum actually provides, or how much it is lacking, see Can a TCP checksum fail to detect an error? If yes, how is this dealt with?.

If you need more protection, you need to have additional and longer protection, because the more bits are used in protection, the better protection can be provided. If you need protection against active tampering with the traffic (ie not just accidental errors), you also need a cryptographic protection, such as offered by TLS.

Is it redundant to add an extra checksum or CRC in TCP payload to make it possible for the receiver verify whether the data is same with the sent one?

1 Answers1