[tsvwg] UDP Options: how to do FRAG without LITE and forced UDP CS=0

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

Greetings,

The version of FRAG defined in draft-ietf-tsvwg-udp-options-07 suffers
from the following disadvantages:

1) A legacy host that does not understand UDP options will erroneously
interpret FRAG without LITE as a complete UDP datagram.
2) The same is true for an options-aware host if OCS fails.
3) Because LITE data (by design) is not covered by OCS/CCO, FRAG+LITE
will have very poor middlebox traversal properties unless the UDP
checksum is set to zero.  For IPv6, even that will not work well,
because UDP CS=0 is often blocked by the network (this happened on
26%-36% of the paths in Raffaele Zullo's recent measurements)

All of these disadvantages can be avoided if the fragment data is
pulled into the option. That can be done as follows: instead of having
the FRAG option capture preceding conventional or LITE user data as
fragment data, insist that the FRAG option appear ***last*** in the
option list and have it capture all remaining octets in the packet as
fragment data. The length field is no longer needed (it is implicit),
so it can be replaced by a More Fragments (MF) flag. By convention, if
this option appears, OCS would cover all UDP options as well as all
octets in the UDP trailer that follow the FRAG option; thus, there
would be no need for a separate overall checksum -- the reassembled
datagram would be protected in a manner equivalent to the way TCP user
data is protected by the checksums on individual segments.

The revised FRAG option formats would be as follows:

                   +--------+--------+--------+--------+
                   | Kind=6 | MF=1  |  Frag. Offset   |
                   +--------+--------+--------+--------+
                   |          Identification           |
                   +--------+--------+--------+--------+
                   |       ... Fragment Data ...       |
                   +--------+--------+--------+--------+

               UDP non-terminal FRAG option format

                   +--------+--------+--------+--------+
                   | Kind=6 | MF=0  |  Frag. Offset   |
                   +--------+--------+--------+--------+
                   |          Identification           |
                   +--------+--------+--------+--------+
                   |       ... Fragment Data ...       |
                   +--------+--------+--------+--------+

                     UDP terminal FRAG option format

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, we just omit the OCS option (in line with the
proposal to always tie the presence or absence of OCS to the user UCP CS
setting). By not having a distinct overall checksum for the reassembled
packet, this version of FRAG avoids duplicate work (just as FRAG+LITE does
in the -07 draft). Having the OCS cover the data in each fragment provides
protection that is essentially the same as what TCP provides with
checksums and sequence numbers on individual segments, if the user has
requested a checksum. 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. The result is essentially equivalent to what is
provided by the post-reassembly checksum in the -07 draft, the main
difference being that the options are also included. Note that ACS is
still available if a stronger post-reassembly checksum is wanted.

I believe that this proposal squarely addresses the disadvantages of the
-07 version of FRAG that are enumerated at the beginning of this message.
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