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

[Joe Touch <[e-mail]>]

Hi, Mike, 

Intriguing as this is, I think you've overlooked two key design goals: 

1) we're not here to fix UDP CS=0. it either works or it doesn't. if
middleboxes are broken, they need to be fixed. 

in short, we cannot - and should not try to - make protocols robust to
arbitrary implementation errors. UDP isn't "byzantine robust" 

2) the FRAG+LITE current design moves only a small, fixed number of
bytes. 

The solution below doesn't appear to avoid copying/moving large amounts
of data. 

At a minimum, can you address #2? If we can do this without moving
around a lot of data, it might be viable. 

Some further points embedded below... 

Joe

On 2019-06-28 09:23, C. M. Heard wrote:

> 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.

I thought we converged to "don't use FRAG without LITE until you confirm
the other end speaks UDP options". What's the reason for needing FRAG
without LITE? 

> 2) The same is true for an options-aware host if OCS fails.

If OCS fails, why would an options-aware host do anything further with
the packet? 

> 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)

That's a significant bug, but we really shouldn't design protocols
simply to get around bugs. 

At least one reason is that IPv6 UDP CS=0 is valid for tunnels and needs
to be supported. 

> 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.

Frag reassembly is not the same as TCP reconstitution. Our IDs do not
operate in sequence, 

> 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