BSDCan2013 - Final
BSDCan 2013
The Technical BSD Conference
| Speakers | |
|---|---|
|
Henning Brauer |
| Schedule | |
|---|---|
| Day | Talks - Day 2 - 2013-05-18 |
| Room | MNT 202 |
| Start time | 13:30 |
| Duration | 01:00 |
| Info | |
| ID | 372 |
| Event type | Lecture |
| Track | Hacking |
| Language used for presentation | English |
The surprising complexity of checksums in TCP/IP
reworking the checksum handling in the OpenBSD network stack
The well-known IP and TCP/UDP (and less well known, ICMP) checksums seem pretty much straighforward. Digging into the network stack reveals a surprising complexity dealing with them and updating. The rise of hardware checksum offloading didn't exactly make things easier.
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.