[tsvwg] Issues with FRAG changes in draft-ietf-tsvwg-udp-options-19

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

On Tue, Dec 27, 2022 at 8:11 PM [e-mail] <[e-mail]>
wrote:

> This incorporates all pending updates, notably the change to the DOS
> (datagram offset start) that was pending.
> It also addresses some of the security issues raised, though we look
> forward to having the security directorate provide a review based on a
> complete read of the document.
>

Hello everyone,

In this message I address just the changes to DOS in Section 9.4, with
other matters being deferred to a subsequent email.

Unless I am missing something, the changes made to the fragmentation text
regarding the DOS (datagram offset start) field in the terminal FRAG option
result in an incoherent specification. I think that these changes need to
be rolled back to what was in -18 (modulo polishing of the rough edges) or,
alternatively, a corrected description of the semantics of DOS in *atomic*
terminal fragments needs to be crafted.

Here is the text from Section 9.4, p. 18, that was added in going from -18
to -19:

   If DOS is larger than Frag. Start of the first fragment (offset=8),
   then all the per-packet options occur before the user data as it is
   reassembled. If DOS points to the end of the original IP packet,
   then there are no per-packet options. If DOS is smaller than Frag.
   Start of the first fragment, then it indicates the end of the per-
   fragment options (of the first fragment) and the start of per-packet
   options (of the reassembled user data). The DOS field enables the
   FRAG option to precede other options in every fragment and to enable
   all packet options to precede user data, enabling easier support for
   reassembly offload via DMA and to support limited router option
   processing hardware.


The scheme as described above  was the subject of a thread back in April
2022.  The fundamental problem with it is that Datagram Option Start (DOS)
indicates the start of the surplus area of the reassembled UDP
datagram, *as measured
from the start of the original UDP datagram*. Frag. Start, on the other
hand, indicates the location of the beginning of the fragment data, *as
measured from the  beginning of the UDP header of the fragment*. As I
pointed out in
https://mailarchive.ietf.org/arch/msg/tsvwg/qbycDNzK41ZijjEip57VUwd1SZA/,
these two quantities are *incommensurate*, as they refer to offsets in
*different* packets. In
https://mailarchive.ietf.org/arch/msg/tsvwg/d0BTAJjPIlxYH5OAdxcB5ckOgFc/,
Joe Touch replied:

They are intended to be commensurate ONLY In atomic fragments. I never
> intended for this to be viable with non-atomic fragments,
>

However, that's not what the text in -19 says. In
https://mailarchive.ietf.org/arch/msg/tsvwg/B1Si2S_3GHi4hEqI8fbPXRg21OI/ Joe
went on to add:

Ps - it might be a LOT simpler to say that limited routers should use only
> per fragment options. We can then leave things as they are and avoid the
> complexity of varying format interpretations.


As I said at the time, I would MUCH prefer to see that than to have varying
interpretations of the terminal FRAG option depending on whether it is or
is not atomic. And in
https://mailarchive.ietf.org/arch/msg/tsvwg/uAS9sgOpk36t03hjRVvVdNeBehU/,
Joe seemed to agree:

>
> Additionally, this approach allows UDP fragmentation as BITW, which could
> be useful in traversing paths with [....] MTU limits.
>
> The only downside is limiting options to per frag for constrained
> implementation routers, which seems like a reasonable compromise to me.
>
> I think that a strong argument can be made that the intended purpose of
changes to the interpretation of DOS in atomic fragments can be served just
as well by per-fragment options. That purpose is to support "limited router
option processing hardware," in other words, systems that can process
packet data (apart from Internet checksum offload) only within a limited
distance from the start of the packet. Such systems are not capable of
parsing options in trailers appended to long packets. Neither are they
capable of processing the entirety of the payload of long packets.  That
capability, however, is needed to support payload-dependent options such as
APC, AUTH, and UENC, irrespective of where those options are located. But
in an atomic terminal fragment, there is no semantic distinction between
per-fragment and per-datagram options that do not depend on the UDP user
data, such as MDS, MRDS, REQ, RES, and TIME. So, to my mind, there is no
point in changing the interpretation of the DOS field in atomic fragments
to accommodate such systems. Just use per-fragment options.

Here are the specific changes that I propose to the text of -19 Section 9.4:

On p. 18, replace

   The terminal FRAG option format adds a Datagram Option Start (DOS)
   pointer, measured from the start of the original UDP datagram
   header, indicating the end of the reassembled data and the start of
   the surplus area after the original UDP datagram. UDP options that
   apply to the reassembled datagram are contained in the partially
   reassembled payload, as indicated by DOS. UDP options that occur
   within the fragment are processed on the fragment itself. This
   allows either pre-reassembly or post-reassembly UDP option effects,
   such as using UENC on each fragment while also using TIME on the
   reassembled datagram for round-trip latency measurements.

   If DOS is larger than Frag. Start of the first fragment (offset=8),
   then all the per-packet options occur before the user data as it is
   reassembled. If DOS points to the end of the original IP packet,
   then there are no per-packet options. If DOS is smaller than Frag.
   Start of the first fragment, then it indicates the end of the per-
   fragment options (of the first fragment) and the start of per-packet
   options (of the reassembled user data). The DOS field enables the
   FRAG option to precede other options in every fragment and to enable
   all packet options to precede user data, enabling easier support for
   reassembly offload via DMA and to support limited router option
   processing hardware.


with

   The terminal FRAG option format adds a Datagram Option Start (DOS)
   pointer, measured from the start of the original UDP datagram
   header, indicating the end of the reassembled data and the start of
   the surplus area after the original UDP datagram. UDP options that
   apply to the reassembled datagram are contained in the
   reassembled payload, as indicated by DOS. UDP options that occur
   within the fragment are processed on the fragment itself. This
   allows either pre-reassembly or post-reassembly UDP option effects,
   such as using UENC on each fragment while also using TIME on the
   reassembled datagram for round-trip latency measurements.

   Some devices are capable of parsing only a limited amount of data
   following the start of the received IP packet and thus need for
   all options to precede the user data.  Limited support for such
   devices can be provided by using per-fragment options.


On p. 20, delete the following paragraph:

      Note: per packet options can occur either at the end of the
      original user data or be placed after the FRAG option of the
      first segment, with the Datagram Option Start (DOS) in the
      terminal FRAG option set accordingly. This includes its use in
      atomic fragments, where the terminal option is the initial and
      only fragment.


I think that the proposed update remains consistent with the final sentence
on p. 20, i.e.,  "Users MAY also select the FRAG option to support limited
header processing." If we want to drop that claim, the second replacement
paragraph above ("Some devices ...") can also be dropped.

I'll address other issues in -19 in a forthcoming message. Hopefully those
issues will be uncontroversial and easy to deal with.

Thanks and regards,

Mike Heard