[e2e] purpose of pseudo header in TCP checksum
David P. Reed
dpreed at reed.com
Tue Feb 15 04:39:39 PST 2005
As I was there (in 1976, when we split TCP into IP, TCP, and other
protocols, such as UDP) for the decision to separate the checksums and
to create a pseudo-header, here is the rationale, which is highly relevant.
TCP (and UDP) are end-to-end protocols. In particular, the TCP
checksum is "end-to-end". It is a "private matter" between end points
implementing the TCP layer, guaranteeing end-to-end reliability, not
IP is a wrapper for TCP, which instructs the transport layer (the
gateways and routers) where the packet is to be transported, how big it
is, and how it may be fragmented in the process of delivery..
The Source Address, Destination address, length, etc. are part of the
meaning of the TCP frame - in that the end point machines use that
information in the TCP application.
Thus the function of SA, DA, etc. are "shared" because they are
meaningful to both layers (IP and TCP). Rather than include the same
information twice in the packet format, the concept of a "virtual
header" was invented to encapsulate the idea that IP is not allowed to
change the SA and DA because they are meaningful.
Further, in the case of end-to-end encryption (in 1976 we had a complete
design by Steven T. Kent, my office mate, which was blocked by NSA from
being deployed) it is essential that all end-to-end meaning be
protected. The plan was to leave the SA and DA in the clear, but
encrypt the rest of the TCP payload, including the checksum. This would
protect against a man-n-the-middle attack that delivered valid packets
with an incorrect source address, etc. (yes, to be truly reliable, we
would have had to use a DSA instead of the current checksum).
This was a careful design decision, wrecked irrevocably by the
terrorists who invented NAT (which doesn't allow end--to-end encryption,
because NAT is inherently a "man-in-the-middle" attack!).
The rise of the middleboxen have now so thoroughly corrupted the
Internet protocol design that it's not surprising that the original
designs are difficult to decode. If we actually had end-to-end
encrypted TCP (now impossible because of the NATs) we would have a much
more secure and safe Internet, while preserving its open character.
Instead we have a maze of twisty, disconnected passages, vulnerable to a
More information about the end2end-interest