The surprising complexity of checksums in TCP/IP

It goes so far that the old "pseudo header checksum" hack where parts of the checksum are precaclucated on the template PCBs and updated on the way out made its way into some of the hardware offloading engines.

The talk explains how IP and protocol (UDP/TCP and ICMP) checksums are handled in the OpenBSD network stack and pf, both traditionally and after redesigning. This includes a closer view on performance impact - while the IP checksum only covers the header, the protocol checksums cover the entire payload, which makes them comparably expensive to verify recalculate. While the actual math is dirt cheap, the data access is not, and for forwarded packets we would not access the payload otherwise. Several different output pathes like the regular IP output, the bridging case and various tunneling/encapsulation mechanisms make things harder.

The redesigned checksumming mechanism pretty much centralizes the checksum handling instead of having it all over the place, making dealing with the checksums in the rest of the stack much easier. It also allows us to benefit a little more from the NICs' offloading capabilities and fixes a long-standing bug which prevented us from enabling protocol checksum offloading on the RX side on many chipsets.