Packet Checksums

Question

I recently learned that every packet includes checksum bytes and that the computer will request the packet again if the checksums don't match. How do the following attacks defeat such a safeguard?

ARP Spoofing - I assume that this is able to take place because the attacker is not actually modifying the packet contents, just intercepting them in transit and then relaying them to the original, intended recipient. Am I correct?

Insertion Attacks (via ARP spoofing) - By insertion attacks I'm referring to text and image replacement and substitution. In this instance, while the attacker performs the same type of attack as above, I know he must be modifying the packet's content (changing text or images). So why doesn't the recipient reject the packet?

Can checksums be recalculated or regenerated after the packet is modified?

Answer 1

Packet checksums are not cryptographic measures, and are not intended to be a security feature. Anyone (even an attacker) can calculate the checksum for a packet containing anything, and there's no secrets/keys involved in the calculation.

Checksums are intended to catch errors during the transmission of the packet: flipped bits, miscommunication, etc. Basically, they're there for reliability, not security.

Answer 2

Not only can checksums be recomputed after a packet has been modified. This happens during normal operation of IP.

It is not at all unusual for a router to have to update three different checksums on a packet before it will be able to forward an unmodified payload.

The three checksums I am referring to are on the Ethernet, IP, and transport layers of the networking stack.

The Ethernet checksum need to be computed again because after forwarding by a router, it is in fact an entirely new Ethernet frame being sent on a different Ethernet segment. Usually the checksum on the incoming packet is verified and stripped by the hardware, and the checksum on the outgoing packet is added by the hardware. The two are checksums are completely independent from each other by design, because IP is designed to work with different physical layers, so incoming packet could be Ethernet and outgoing something else or vice-versa.

The IP header checksum need to be computed again because the router actually has to modify the IP header in order to decrease TTL.

The transport checksum (usually UDP or TCP) shouldn't need to be updated. IP is designed such that the router doesn't even need to know the transport protocol. However due to the internet still running the obsolete version 4 of the protocol, lots of NAT devices have been deployed which modify some of the fields covered by the transport checksum. When this happens, the router need to update the transport checksum as well. This has been optimized to the point, where the router doesn't even look at the entire payload in order to recompute the checksum. By considering just the old checksum as well as the old and new value of the modified field, the new checksum can be computed. All of this is usually done without modifying the payload.

Much of the above changes with IPv6. The part about Ethernet checksums is still the same. But the IP header checksum was removed to simplify and speed up processing, it was redundant anyway when both the layers beneath and above IP would checksum the data. Additionally the modifications of transport checksum in-flight was a workaround due to limitations in IPv4. Such modifications are no longer needed.

None of this is related to security. If you want security against malicious modification of packets, you don't rely on checksums, instead you rely on message authentication codes. The standardized protocol for this is called IPsec and in IPsec terminology, the MAC is called an integrity check value, because strictly speaking the ICV could be a signature instead of a MAC.