Checksum offloads and protocol ossification

Posted Dec 8, 2015 21:19 UTC (Tue) by yootis (subscriber, #4762)
Parent article: Checksum offloads and protocol ossification

Is there even value in checksums in headers anymore? All of the transport mechanisms like ethernet already have much more powerful CRCs. I've never heard of packets getting delivered with bad checksums, so why are they even used?

Checksum offloads and protocol ossification

Posted Dec 8, 2015 21:45 UTC (Tue) by josh (subscriber, #17465) [Link]

Bad checksums do happen; among other things, I've seen case studies of them happening due to memory errors. Also see http://dinaburg.org/bitsquatting.html , and notice the mentions that bit errors at some phases of the process will get rejected due to checksums.

Some protocol in the stack needs to have *cryptographic* integrity; for instance, TLS provides cryptographic integrity guarantees. However, at the lower levels, a quick checksum to confirm valid packet delivery allows the network stack to say "didn't get that, send it again", transparently to the application, as part of the normal ACK/NAK process.

Also see https://en.wikipedia.org/wiki/End-to-end_principle .

Checksum offloads and protocol ossification

Posted Dec 9, 2015 9:13 UTC (Wed) by paulj (subscriber, #341) [Link]

They can protect against bugs in between the checksum being calculated and the packet passing through the L2 CRC engine.

I've seen weird driver bugs where chunks of packets were being dropped after being sent by userspace. The L2 CRC was fine, but the kernel applied header checksum was wrong. Turned out to be a subtle bug in the proprietary forwarding hardware driver, on raw sockets, iirc.