Re: [tsvwg] Alternative version of the UDP FRAG option

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

On Tue, Mar 12, 2019 at 8:39 PM Joe Touch wrote:
>  On Mar 12, 2019, at 11:26 PM, C. M. Heard wrote:
[ ... ]
> > So, CS=0 does have its risks even for the length field.
>
> Fair enough. Now show us how to avoid that without recopying the
> payloads and/or recomputing the checksum twice.
>
> That’s the issue. A fix for a problem that current UDP already deals
> with and doesn’t come up vs so much extra work the result won’t be
> useful.

That is a fair request, considering that I have sowed ample confusion
by floating three variations of my proposal, and only the last achieved
that result. Here it is, again:

Maintain the format of the FRAG option as currently defined for a
non-terminal fragments, and allocate a new KIND to indicate a
terminal fragment. Both kinds would have the same format:

                   +--------+--------+--------+--------+
                   |  Kind  | Len=10 |  Frag. Offset   |
                   +--------+--------+--------+--------+
                   |          Identification           |
                   +--------+--------+--------+--------+
                   |    Checksum     |
                   +--------+--------+


The following requirements would apply:

   >> When the FRAG option appears, it MUST come last in the UDP options
   list.  All remaining octets in the packet are interpreted as fragment
   data.


   >> OCS, if present, covers both the FRAG option and the trailing
   fragment data.


   >> A host that wishes to signal that it is able to accept and process
   the FRAG option MAY do so by transmitting an unfragmented datagram
   with an empty terminal FRAG option whose Offset field is set to zero.


   >> Non-empty FRAG options MUST NOT be present in packets with ordinary
   UDP user data or LITE data. Any such options MUST be silently dropped.


   >> UDP options other than OCS and padding MUST NOT accompany the FRAG
   option in non-terminal fragments.  Any such options MUST be silently
   dropped.  All other options that apply to a reassembled packet must
   accompany the FRAG header in the terminal fragment.


To handle the case when the user UDP CS setting specifies that the UDP
checksum should be zero, then OCS would not accompany the FRAG option.
Otherwise it would, irrespective of the user OCS setting.

This version does not have a distinct overall checksum for the reassembled
packet, and so avoids duplicate work. Having the revised OCS cover the data
in each fragment provides protection that is essentially equivalent to that
provided by the post-reassembly checksum proposed in the current draft. For
in order to deliver the reassembled data, we require all fragments to be
present and to fit together exactly with no gaps and no overlap. Thus,
having each fragment pass its checksum is equivalent to passing an overall
checksum that covers the reassembled data plus the options. Note that ACS
is still available if a stronger post-reassembly checksum is wanted.

I think this answers the important objections. It offers a solution that
provides protection equivalent to conventional IP fragmentation coupled
with the standard UDP checksum, allows for middlebox traversal, and avoids

duplicate checksum computations.


Mike Heard