Re: [tsvwg] UDP Options: on forcing the use of UDP CS=0 in connection with FRAG+LITE

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

On Tue, Jul 2, 2019 at 11:07 AM Tom Herbert <[e-mail]> wrote:
> On Tue, Jul 2, 2019 at 10:33 AM C. M. Heard <[e-mail]> wrote:
> >    o  A UDP application MUST check that the source and destination IPv6
> >       addresses are valid for any packets with a UDP zero-checksum and
> >       MUST discard any packet for which this check fails.  To protect
> >       from misdelivery, new encapsulation designs SHOULD include an
> >       integrity check at the transport layer that includes at least the
> >       IPv6 header, the UDP header and the shim header for the
> >       encapsulation, if any [RFC6936].
>
> Mike,
>
> Right. Conceptually the reassembly checksum could meet the criteria if
> the IP addresses were included, but that would break in the presence
> of NAT since no NAT devices are going update a new checksum field
> (with the possible exception that NAT makes a checksum neutral changes
> as described in RFC6296).
>
> So the best approach is to not touch the UDPv6 checksum and to ensure
> that the surplus area sums to zero (i.e. the UDP checksum effectively
> covers both the UDP payload and surplus area). As I've mentioned
> previously, this motivates putting a required checksum field in the
> surplus space not just in an option like OCS. A per packet checksum in
> surplus area has other benefits beyond making UDP checksum compatible
> with middleboxes.
>
> Tom

In https://mailarchive.ietf.org/arch/msg/tsvwg/_RKlp1O4JgfCUoWBr2L5VKLCj_M
I proposed something very similar to that:

(a') OCS must be included by a sender whenever the UDP checksum is enabled
     (I agree that OCS seems pointless when the user has requested CS=0)
(b') OCS, when present, should provide coverage from the start of the
     options area (before LITE is moved on transmit or after it is moved on
     receive) to the end of the packet

That indeed does provide advantages beyond middlebox traversal, not the
least of which is that OCS can be verified ***before*** one loops through
all the option TLVs.

Being agnostic on whether anything after the end of the UDP options (if
marked by an EOL option) should be allowed, I see no particular advantage
to having a fixed header as described in draft-herbert-udp-space-hdr as
opposed to the OCS and NOP options, assuming that OCS has an implicit
length of two. If we require two-byte or four-byte alignment, then the
latter combination will consume less space than the fixed header when the
regular UDP payload ends on a byte boundary that is 1 mod 2 or 1 mod 4
(respectively), and if we don't constrain the placement of OCS, it may
consume less space in other cases as well. It will always consume less
space if we don't levy an alignment requirement.

Also, I'm of the opinion that an optional-to-implement capability for the
user to specify UDP CS=0 for a particular port (in conformance with
Section 4 of RFC 6936) should be retained when UDP options are enabled.
If (as Joe and I argue) OCS is pointless in that case, we might as well
save space by omitting it, which not possible with a fixed header.

Mike