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

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

On Tue, Mar 12, 2019 at 3:09 AM Joe Touch wrote:
> > On Mar 12, 2019, at 2:00 AM, C. M. Heard wrote:
> > Yes, but FRAG+LITE fails the deployability test. That IMHO makes it a
> > non-starter.
>
> That is lite alone only AFAICT.

I don't think that is the case. As stated in the -07 draft (and
reiterated in subsequent email discussions), the fact that OCS
does not cover LITE data defeats its ability to compensate for
the middlebox checksum bug, whether used alone or in combination
with FRAG:

   Note that this incorrect checksum traversal feature is defeated by
   the use of LITE, whether alone or with FRAG, because the LITE area
   is deliberately not covered by OCS. It also is defeated by the use
   of a zero UDP checksum (i.e., UDP checksum disabled).

Unless I've missed something, the only proposal on the table that
allows FRAG+LITE to traverse middleboxes with the checksum bug is
to disable the UDP checksum (i.e., set it to zero), and as pointed
out by Raffaele Zullo, that has its own downsides (no protection
for the UDP length or the port numbers).

A revised OCS (that includes the pseudo-header correction) will allow
FRAG **without** LITE (as proposed in the draft) to traverse the
affected middleboxes with a non-zero UDP CS, but that method has the
following downsides:

1) A legacy host interprets FRAG without LITE as a complete UDP datagram
2) The same is true for an options-aware host if OCS fails
3) There is duplicate checksum coverage (UDP checksum covers each fragment,
   plus post-reassembly checksum contained in the terminal FRAG option)

FRAG+LITE solves all three of these problems (rather elegantly IMHO)
but unfortunately at the cost of poor middlebox traversal properties,
a fact that was not known until the work of the CCO folks.

Unlike LITE, which is a nice-to-have feature that the world has so
far managed to live without, the main reason for wanting FRAG is
because IP fragments have poor middlebox traversal properties
(especially IPv6), and for some use cases (e.g., DNSSEC), there
is no viable alternative. If IP fragmentation did not suffer
from middlebox traversal issues, we would not need FRAG.

So, from my perspective, FRAG is not very useful unless we can
solve both middlebox traversal and at least problems 1+2 above.
AFAICT, the proposal I floated at the beginning of this thread:

>>> maintain the format of the FRAG option as currently defined, but instead
>>> of having the option capture preceding conventional or LITE user data as
>>> fragment data, insist that it appear ***last*** in the option list and
>>> have it capture all remaining octets in the packet as fragment data. 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.

does just that. Granted, it does not solve problem 3, but the following
variant would: omit the overall checksum from terminal FRAG option and
use a different option Kind instead. Require OCS to be present in all
fragments whenever the user UDP CS setting specifies that the UDP
checksum must be present, irrespective of the user OCS setting.

AFAICT, forcing the revised OCS to cover the data in each fragment
provides protection that is essentially equivalent to that provided
by the proposed post-reassembly checksum. For in order to deliver the
reassembled data we require all fragments to be present and fit
together exactly with no overlap. ACS is available if a stronger
post-reassembly checksum is wanted.

> Again, we need to include fixing these errors. If we let every bug
> persist, nothing would be deployable anymore.

I totally agree with that. But it can be a very long game, as the
recent DNS flag day (when major implementations finally turned EDNS0
workarounds off) illustrates.

Mike Heard