[e2e] purpose of pseudo header in TCP checksum

[David P. Reed]

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 
hop-by-hop reliability.

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 
zillion hackers.