[tsvwg] Discarding the UDP surplus area when protocol-agnostic checksum offload is used

["C. M. Heard" <[e-mail]>]

On Tue, Apr 9, 2024 at 8:17 AM Tom Herbert wrote:
> In current host stack implementation, when a UDP packet is received
> with surplus area we truncate the packet down to UDP Length and
> otherwise ignore the surplus area bits. Are you suggesting that the
> default behavior should be to drop packets with a UDP surplus area?
>
> IMO, this might be worth considering. I agree that this would tighten
> security. Also, I would point out that even truncating the surplus
> area like we do today is not without cost. If we are doing protocol
> agnostic checksum offload, the preferred method, then we need to
> compute the checksum over the surplus area when truncating and so we
> do this in the CPU. For a large surplus area this can burn a lot of
> cycles to process data that is useless to the receiver; conceivably,
> this could be a basis for a DoS attack on CPU resources.

Hi Tom,

One question that I have is whether existing host stack implementations
that use protocol-agnostic checksum offload typically do go to the
trouble of computing the compensating checksum for the surplus area,
which of course is identical to the OCS computation specified in the
UDP Options spec. The main motivation for why OCS is specified in
that way is because of the bugs found in middleboxes that erroneously
use the IP Payload Length rather than the UDP Length to calculate the
UDP checksum. The bug also seems to afflict some end systems. See:

https://datatracker.ietf.org/meeting/103/materials/slides-103-maprg-a-tale-of-two-checksums-tom-jones

https://tma.ifip.org/2020/wp-content/uploads/sites/9/2020/06/tma2020-camera-paper70.pdf

In end systems affected by this bug, one side effect would be that
packets with a correct UDP checksum and UDP options with a properly
calculated OCS would be accepted by tsuch systems, whereas arbitrary
packets with a non-empty surplus area likely would not!

Mike Heard