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

[Tom Herbert <[e-mail]>]

On Mon, Jul 1, 2019 at 12:16 PM C. M. Heard <[e-mail]> wrote:
>
> On Sat, Jun 29, 2019 at 7:58 AM Joe Touch wrote:
> >
> > See sec 8.1, which incorporates rfc 6936:
> >
> >          As an exception to the default behavior, protocols that use UDP
> >          as a tunnel encapsulation may enable zero-checksum mode for a
> >          specific port (or set of ports) for sending and/or receiving.
> >          Any node implementing zero-checksum mode must follow the
> >          requirements specified in "Applicability Statement for the Use
> >          of IPv6 UDP Datagrams with Zero Checksums" [RFC6936].
> >
> > Frag is a kind of such a tunnel because it adds its own reassembly CS.
>
> I'll agree that FRAG+LITE with UDP CS=0 does conform to the requirements
> in RFC 6936 Sections 4 and 5 because it includes a reassembly CS.
>
Mike,

The reason that UDPv6 checksums were required in the first place is
that IPv6, unlike IPv4, has no header checksum. The pseudo header in
the UDP checksum includes the IP addresses which provides protection
against misdelivery when addresses are corrupted. The UDP options
reassembly checksum doesn't include the pseudo header so it provides
no protection of the IP addresses, and hence I don't believe it
satisfies the requirements of RFC6936 for using a zero UDP checksum.

> > But that also means middleboxes should allow relaying these since 6936
> > was passed.
>
> Yes. middleboxes are ***supposed*** to do that. But the empirical data
> that we have says that in a significant number of cases (affecting 26%-36%
> of the paths) they do not.
>
Thanks for the numbers, that is very enlightening.

> It's possible that the situation will improve in the future, but given
> that it has not improved enough to make UDP CS=0 useable in other than
> controlled environments, I don't think it's a good idea to propose its
> use when we have an alternative that avoid UDP CS=0 that is no more
> complex to implement.

Agreed. I'd also point out that the very reason to force UDP checksum
to zero is that some implementations incorrectly compute the UDP
checksum based on length of the packet as opposed to using UDP length.
Unlike expecting devices to accept UDPv6 zero checksums when prior to
RFC6936 was strictly prohibited for all cases, basing UDP checksum on
packet length was _never_ allowed. IMO,  forcing zero checksums is at
best trading off one source of brokenness for another, but the numbers
you're reporting don't seem justify the tradeoff is worth it.

Tom

>
> Mike Heard