0

I was just working my way through the RFC for UDP Lite and got stuck at Section 5 when compatibility with UDP is discussed: https://www.rfc-editor.org/rfc/rfc3828#section-5

In the RFC it says a UDP-Lite packet with partial checksum coverage will be discarded when received by a UDP Implementation "because a mismatching pseudo header would cause the UDP checksum to fail."

However in Section 3.2 (https://www.rfc-editor.org/rfc/rfc3828#section-3.2) it says: "The pseudo header of UDP-Lite is different from the pseudo header of UDP in one way: The value of the Length field of the pseudo header is not taken from the UDP-Lite header, but rather from information provided by the IP module."

But doesn't that mean that in fact UDP and UDP-Lite pseudo headers are the same (only that the informationen about packet length is taken from a different source?)

Indeed i understand why checksum calculation fails: When UDP Lite checksum only covers parts of the package while a classic UDP implementation will calculate checksums over the whole package content, a different checksum will result. But then failure is not due to a different pseudo header, is it?

Kindly correct me if my understanding so far is wrong...

Community
  • 1
  • 1
user1774249
  • 73
  • 2
  • 6

1 Answers1

0

If you only do a partial checksum in UDP-lite then the failure when checksummed as a UDP packet is indeed not due to a different pseudo-header, as you state.

However, I think that it's possible for a complete UDP-lite checksum to fail when interpreted as UDP:

  • The IPv4 header contains a total length field and an IP header length field.
  • The UDP header contains a UDP datagram length field.

  • You'd generally have (with IP header length multiplied by 4 to give octets):

    Computed UDP datagram length = IP total length - IP header length

    and you'd expect to have the equality:

    UDP datagram length field == Computed UDP datagram length

However, there's nothing that guarantees this: you could have trailing garbage after the UDP datagram but still within the IP packet. This would cause Computed UDP datagram length to be greater than UDP datagram length, thereby making the UDP and UDP-Lite checksums different.

AFAICT nothing in UDP or IP prohibits this situation, but I'm not aware (a) of any way to create it without using a raw socket, or (b) what a receiving UDP peer would do about it.

user3392484
  • 1,929
  • 9
  • 9
  • if i correctly understand the rfc at section 3.4 (http://tools.ietf.org/html/rfc3828#section-3.4) it says, the underlying IP module is prohibited to additionally pad the ip payload. So that would prohibit the case you just described? Anyway thanks a lot for your answer, so concerning the failure of checksums the rfc is apparently wrong or not very precise... – user1774249 Mar 15 '14 at 16:45
  • Ah yes. Hadn't noticed that bit. Given that, the only cause of a UDP / UDP-Lite mismatch ought to be a partial checksum, rather than anything due to packet length. Would want to read IP, UDP and UDP-Lite specs carefully to be sure though. – user3392484 Mar 15 '14 at 17:02