Re: [tsvwg] Way forward for UDP option FRAGs with limited router hardwara

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

On Tue, Apr 12, 2022 at 9:46 AM Christian Huitema wrote:
> On 4/12/2022 9:17 AM, C. M. Heard wrote:
...
> > There is a concern that packets with UDP trailers -- i.e., where
> > the IP Payload Length exceeds the UDP Length -- will be filtered in
> > intermediate systems. If I understand correctly, this is the concern
> > (or at least one of the concerns) that Christian Huitema has raised.
> > The Aberdeen group has actually investigated this matter, and Tom
> > Jones presented the results at a MAPRG meeting several years ago.
> > I'll search my archives and provide appropriate pointers to that
> > work in a bit.
>
> Thanks. Waiting to see the data.

The 2018 MAPRG presentation authored by Gorry Fairhurst, Tom Jones, and
Raffaele Zullo is available at:

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

There is a more recent published paper by Zullo, Jones, and Fairhurst
resulting from this work; it is available at:

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

The principal finding was that UDP options, as originally envisioned,
were blocked quite often by middleboxes re-computing the UDP checksum
as if the options trailer was part of the UDP packet -- in other words,
using the IP Payload Length instead of the UDP Length both to control
the extent of the UDP checksum calculation and as the the length value
used in the pseudo-header. This was the motivation for the way OCS is
specified. It compensates for this middlebox pathology, and in addition,
it happens to make commonly used forms of checksum offload work as
intended in the presence of UDP options -- see
https://mailarchive.ietf.org/arch/msg/tsvwg/9_1YWp-TApI9mcCuia8U6jfCwTA/.

However, the work also considered many other kinds of middlebox
pathologies, including refusal to pass anything that does not have
IP Payload Length equal to UDP Length, passing the surplus area only
if it contained nothing but zeroes, and a couple of other checksum
re-calculation anomalies.

I just became aware of the paper and have yet to digest it, but back
in November 2018 I put several questions to Tom Jones regarding the
interpretation of the figures in the MAPRG presentation. He has
graciously permitted me to forward his response to those questions,
in addition to providing the link to the published paper.

---------- Forwarded message ---------
From: Tom Jones <[e-mail]>
Date: Mon, Nov 26, 2018 at 5:19 AM
Subject: Re: Questions about "A Tale of Two Checksums"
To: C. M. Heard <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>

Hi Mike,

Thanks for your questions and feedback on the TSVWG mailing list.

> A few questions about the IETF 103 maprg presentation "A Tale of Two
> Checksums" came up when reviewing the slides at https://datatracker.ietf
> .org/meeting/103/materials/slides-103-maprg-a-tale-of-two-checksums-tom-
> jones. I'll put the questions here, but If there us a writeup available
> that will answer these questions I'd be happy to have a pointer to it.

We are writing a paper on these measurements and will share it with the
list when it is published.

> On page 10:
>
>    1. Does "Works" mean UDP Length Checksum, UDP length Pseudoheader,
>    surplus area passed transparently?

Yes, UDP datagrams with Options work end to end on that path. (this
includes the correct checksum and when no checksum validation is done on
the path)

>    2. Does "Full Payload Checksum" mean Full Payload Checksum, IP length
>    Pseudoheader, surplus area passed transparently?

Figure 1 in the CCO draft will help.

https://tools.ietf.org/html/draft-fairhurst-udp-options-cco-00

The Full Payload Checksum is calculated over the number of bytes as
described by the IP Payload length. That is, it is calculated over the
UDP Datagram and any surplus space (the option area).

IP Length Pseudoheader here means that the UDP Pseudeoheader constructed
for the checksum uses the length from the IP Payload length and not the
one in the UDP header.

>    3. It seems that "Full Payload Checksum, UDP length Pseudoheader" would
>    get typically through if the options space is populated by zeroes
(since
>    the checksum computation would yield the same value as UDP Length
>    Checksum, UDP length Pseudoheader). How is "Only passes 0s as options
>    space" distinguished from this case?


If zero padded works and 3rd CS fails, it is a problem with the options
space. If 3rd CS passes, zero padded will always work.

If zero padded fails, 3rd CS passes, it falls into the 'other' category.
This is a very small number of cases.

>
> On pages 8+12 and 17-18:
>
>    1. Is the correct reading of these charts that blue = what passes
>    without CCO, blue+red = what passes with CCO?
>

Yes

> On pages 15-16 and 19-20:
>
>    1. In general, do the various colours slices on the graphs indicate the
>    fractions of packets _with options_ (IP payload length <> UDP Length)
>    passed for the various checksum options listed in the key on the
>    following page?


Slides 15-16 and 22 are the same slide, the key was moved to make it
easier to discuss when presenting.

It is the same case for 19-20 and 21.

>    2. Does "No CS" mean "no packets with options passed" (indicating a
path
>    that require IP payload length == UDP Length)?

Yes

>    3. Is "4th CS" the same as "UDP Length Checksum, IP length
Pseudoheader"
>    on p. 10?

Yes

>    4. Is "3rd CS" the same "Full Payload Checksum, UDP length
Pseudoheader"
>    on page 10? If so, is there an additional proviso that the option
space is
>    non-zero?

Yes

>    5.  Does "Zero-Padded Options only" mean the same thing as "Only passes
>    0s as options space" on p. 10? If so, were any checksum combinations
>    other than "Correct UDP CS" (i.e., UDP Length Checksum, UDP length
>    Pseudoheader) included in this test case?

Yes, no other combinations were included.

>    6. Does the colour red indicate paths for which "Full Payload Checksum,
>    IP length Pseudoheader" was the only one that worked for packets
without
>    CCO?

Yes

>    7. Does the colour yellow indicate paths for which both "Correct UDP
CS"
>    and "Full IP Payload CS" worked in the absence of CCO? That this
>    combination was so prevalent seems to indicate that many middleboxes
do two
>    checksum computations!

Yes. The two computations can also happen at different layers, in that case
we get an OR between them.

> Thanks for the work. It was very enlightening, if somewhat discouraging,
> given that there are drop rates in the 5% - 28% range even with CCO.
>
> Mike Heard

- Tom and Raf
------------------------------------------------------------------------

A quick scan of the published paper suggests that many of the questions
I asked -- as well as others -- are resolved there. I shall be reading
it carefully in the next few days. That being said, there is one special
case that deserves to be singled out that, as far as I have seen, is
mot explicitly addressed: what happens when there is no conventional
UDP data at all, i.e., when UDP Length = 8? This case figures
prominently in the current specification, since it is used for
fragmentation, options that cannot be safely ignored, and packets that
carry options with no user data, such as DPLPMTUD probe packets. If
tests were conducted for that case, I at least would find the results
to be of great interest.

Mike Heard