Can a TCP checksum produce a false positive? If yes, how is this dealt with?

views:

answers:

+2 Q:

Can a TCP checksum produce a false positive? 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?

+3 A:

and additional checksums at lower levels

Some of these are stricter than checksums, e.g. Ethernet uses a CRC instead of a checksum.

this might be very, very unlikely but isn't TCP meant to be 100% reliable? How does it resolve these false positives?

I don't think it can. Even if it sent a duplicate via hard copy and carrier pigeon, a cosmic ray or quantum effects might theoreticaly mangle the duplicate too in exactly the same way. It's just very, very unlikely.

You can also implement arbitrarily strong integrity chcking at the application layer (above TCP), e.g. using cryptographic signing.

ChrisW 2010-09-30 11:53:20

Whilst Ethernet has good integrity checking what about other forms of network?

Mr Question McQuestion 2010-09-30 12:01:43

I expect you'd want to engineer the integrity checking to match the error rate of your data link. For example [PPP](http://en.wikipedia.org/wiki/Point-to-Point_Protocol) uses a CRC as well.

ChrisW 2010-09-30 12:06:20

That makes sense. For a long connection over many different data link types (ethernet, ppp, atm) I guess you'll be at the mercy of the worse component link (which might not have integrity checking at all).

Mr Question McQuestion 2010-09-30 12:15:19

@ChrisW - Good point, and the _use_ of your Data Link matters too. If it's critical, go for another layer of protection; you'll only delay the inevitable, though. If it's just transmitting throw-away data, why bother since people won't notice or refresh their query...

samy 2010-09-30 12:18:49

+1 A:

I would imagine the probability is one in a billion million zillion kajillion, because if the TCP data is corrupted, which is the transport layer, it will also mean the other layers (datalink and network) will also be corrupted. I believe at least the datalink layer has a checksum for integrity, so you'd have to have both checksums fail.

Corrupting in such a way that at least two separate checksums fail, is astronomically unlikely, maybe even impossible.

SLC 2010-09-30 11:54:18

Not all datalink layers have integrity checking though do they?

Mr Question McQuestion 2010-09-30 12:00:16

No, they don't. The paper i linked to above mentions the use of application-level checks in some cases

samy 2010-09-30 12:02:56

See http://academic.research.microsoft.com/Paper/22436.aspx , lower level crc might not be as reliable as you think.

nos 2010-09-30 12:13:47

Can a TCP checksum produce a false positive?

Yes. The checksum is considerably smaller than the packet, so many different packets can match a given checksum.

If yes, how is this dealt with?

In TCP, not at all. However, most data corruptions will be noticeable at a higher level, e.g. your XML is no longer well-formed; your email is no longer English, etc.

Bryan 2010-09-30 11:55:29

+3 A:

No it can't be 100% reliable: this paper mentions 1 in 16 million to 10 billion packets not caught by the error control system. I'll let you calculate the occurences per day/week :)

samy 2010-09-30 11:55:44

World traffic is about 10 to the 15 packets per day: so the chance of its happening to some of other people's packets (though not to yours) is pretty high, therefore.

ChrisW 2010-09-30 12:03:58

I think the only metric as to how probable it is for one person to experience it is packet-related; you're as liable to have this problem as somebody else that uses the same amount of packets. OTOH, to be noticeable you'd have to experience the failure in a critical packet; if your html or your js is mangled you frown and just reload the page, you don't whip out the post-mortem tools :) By the way, where did you find your stat? I looked around but couldn't find data about the number of packets...

samy 2010-09-30 12:16:41

I was just pointing out that if the error rate is one in 10 billion then it probably won't happen to you (because you don't send that many packets): but it probably will happen to someone else (because they do, collectively, send more than many packets). The first stats I found were [World 7,500-12,000 PB (PetaByte = 10^15 bytes)](http://www.dtc.umn.edu/mints/), which I divided by my guesstimate of 500 bytes per packet.

ChrisW 2010-09-30 12:22:28

@ChrisW Thanks for the link :) You're more conservative than i would have been regarding the packet size, though, but even by taking the max size of the packet, errors happen daily

samy 2010-09-30 12:22:49

ansaurus

tags:

views:

answers:

Can a TCP checksum produce a false positive? If yes, how is this dealt with?

related questions