22

Why is the Pseudo header prepended to the UDP datagram for the computation of the UDP checksum? What's the rational behind this?

mort
  • 12,988
  • 14
  • 52
  • 97
Priyanka Mishra
  • 10,400
  • 18
  • 62
  • 75

5 Answers5

27

The nearest you will get to an answer "straight from the horse's mouth", is from David P. Reed at the following link.

http://www.postel.org/pipermail/end2end-interest/2005-February/004616.html

The short version of the answer is, "the pseudo header exists for historical reasons".

Originally, TCP/IP was a single monolithic protocol (called just TCP). When they decided to split it up into TCP and IP (and others), they didn't separate the two all that cleanly: the IP addresses were still thought of as part of TCP, but they were just "inherited" from the IP layer rather than repeated in the TCP header. The reason why the TCP checksum operates over parts of the IP header (including the IP addresses) is because they intended to use cryptography to encrypt and authenticate the TCP payload, and they wanted the IP addresses and other TCP parameters in the pseudo header to be protected by the authentication code. That would make it infeasible for a man in the middle to tamper with the IP source and destination addresses: intermediate routers wouldn't notice the tampering, but the TCP end-point would when it attempted to verify the signature.

For various reasons, none of that grand cryptographic plan came to pass, but the TCP checksum which took its place still operates over the pseudo header as though it were a useful thing to do. Yes, it gives you a teensy bit of extra protection against random errors, but that's not why it exists. Frankly, we'd be better off without it: the coupling between TCP and IP means that you have to redefine TCP when you change IP. Thus, the definition of IPv6 includes a new definition for the TCP and UDP pseudo header (see RFC 2460, s8.1). Why the IPv6 designers chose to perpetuate this coupling rather than take the chance to abolish it is beyond me.

TFBW
  • 989
  • 7
  • 12
  • I just thought: may be the reason to save this legacy in IPv6 is that IPv6 allow to escape the NAT, and thus the idea of ciphering the TCP header has revived. – Hi-Angel May 24 '14 at 08:27
  • 1
    Why the IPv6 designers chose to perpetuate this coupling rather than take the chance to abolish it is beyond me. <-- because there is no checksum at the ip layer in v6. – Xavier Nicollet Dec 16 '17 at 07:13
24

From the TCP or UDP point of view, the packet does not contain IP addresses. (IP being the layer beneath them.)

Thus, to do a proper checksum, a "pseudo header" is included. It's "pseudo", because it is not actaully part of the UDP datagram. It contains the most important parts of the IP header, that is, source and destination address, protocol number and data length.

This is to ensure that the UDP checksum takes into account these fields.

mort
  • 12,988
  • 14
  • 52
  • 97
mat
  • 12,943
  • 5
  • 39
  • 44
11

When these protocols were being designed, a serious concern of theirs was a host receiving a packet thinking it was theirs when it was not. If a few bits were flipped in the IP header during transit and a packet changed course (but the IP checksum was still correct), the TCP/UDP stack of the redirected receiver can still know to reject the packet.

Though the pseudo-header broke the separation of layers idiom, it was deemed acceptable for the increased reliability.

jdizzle
  • 4,078
  • 1
  • 30
  • 38
  • Thank you so much for the answer after long time question posting. I am glad after long time after question posting you answered the question instead of just reading and skipping to next question. SO guys really rocks. – Priyanka Mishra Mar 05 '09 at 09:01
  • 3
    Isn't that already taken into consideration in the IP header's checksum? – 0xab3d May 24 '15 at 13:52
  • @0xab3d Let machine X send a packet to machine Z. Assume that on the way, the packet gets corrupted. Due to corruption, the destination of the packet changes to machine Y and the checksum changes in a way that the resulting checksum value fits perfectly with the corrupted data. Now this packet will be delivered to machine Y instead of Z. Y's network layer will also wholeheartedly accept the packet. Now, if the checksum field of the Y's transport layer makes use of 'pseudo-header' in checksum calculation, then there's no issue. Otherwise, Y will accept a packet which was not intended for it. – Argon Jun 11 '20 at 10:07
10

"The purpose of using a pseudo-header is to verify that the UDP datagram has reached its correct destination. The key to understanding the pseudo-header lies in realizing that the correct destination consists of a specific machine and a specific protocol port within that machine. The UDP header itself specifies only the protocol port number. Thus, to verify the destination, UDP on the sending machine computes a checksum that covers the destination IP address as well as the UDP datagram. The pseudo-header is not transmitted with the UDP datagram, nor is it included in the length."

E. Comer - Internetworking with TCP/IP 4th edition.

Uwe Keim
  • 39,551
  • 56
  • 175
  • 291
Tudor
  • 101
  • 1
  • 2
  • 2
    @UweKeim As a beginner I hope that the concept of IP addresses is present in the Network layer and the Transport layer is above it, so how does the Transport layer know the IP address at the sending side because at the sender side, first the transport layer header is first encapsulated around the data coming from Application layer and then the IP header is attached. I mean, how does the Transport layer get to know the IP address when this facility is present at the bottom layer (Network layer) ? – asn Nov 25 '18 at 16:43
1

Pseudo IP header contains the source IP, destination IP, protocol and Total length fields. Now, by including these fields in TCP checksum, we are verifying the checksum for these fields both at Network layer and Transport layer, thus doing a double check to ensure that the data is delivered to the correct host.

Vaibhav Kedia
  • 27
  • 2