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

[Tom Herbert <[e-mail]>]

On Tue, Jul 2, 2019 at 10:33 AM C. M. Heard <[e-mail]> wrote:
>
> On Mon, Jul 1, 2019 at 2:56 PM Tom Herbert wrote:
> > On Mon, Jul 1, 2019 at 12:16 PM C. M. Heard  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.
> > >
> > 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.
>
> Tom, after a more careful review of the relevant specifications I am
> coming around to your point of view on this matter.
>
> The normative requirements in RFC 6936 are in Section 4 (which defines
> requirements and recommendations on the implementation of IPv6 nodes
> that support the use of a zero UDP checksum) and in Section 5 (which
> defines requirements and recommendations for protocols and tunnel
> encapsulations that are transported over IPv6 without performing a UDP
> checksum calculation). Section 3.41 of RFC 8085 reiterates these
> requirements and levies another requirement of its own, which is stated
> in the last bulleted paragraph below:
>
>    o  Use of the UDP checksum with IPv6 MUST be the default
>       configuration for all implementations [RFC6935].  The receiving
>       endpoint MUST only allow the use of UDP zero-checksum mode for
>       IPv6 on a UDP destination port that is specifically enabled.
>
>    o  An application that supports a checksum different than that in
>       [RFC2460] MUST comply with all implementation requirements
>       specified in Section 4 of [RFC6936] and with the usage
>       requirements specified in Section 5 of [RFC6936].
>
>    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

>
>
> So, to fully comply with existing requirements, FRAG+LITE with forced
> CS=0 over IPv6 would have to conform with the following, even when
> the user leaves the UDP checksum enabled for non-fragmented packets:
>
> 1.) The implementation would have to default to disabling FRAG+LITE,
> i.e., unless the application using a particular port specifically
> requests it, do not transmit datagrams fragmented in this manner and
> do not accept datagrams fragmented in this manner (RFC 6936 Section 4,
> requirements 2-5, RFC 6936 Section 5 requirement 1, and first bulleted
> paragraph above). Ideally, this would be an API switch distinct from
> those that allow UDP CS=0 in general, so that allowing it for FRAG+LITE
> would not open up the floodgates for arbitrary UDP CS=0 datagrams. This
> would require updates to Section 9 of draft-ietf-tsvwg-udp-options-07.
>
> 2.) A transport layer checksum must be provided. The reassembly CS in
> draft-ietf-tsvwg-udp-options-07 satisfies this requirement.
>
> 3.) A UDP application, or the transport layer working on its behalf,
> MUST verify that the source and destination IPv6 addresses are valid
> in any received packet that uses FRAG+LITE with CS=0 (RFC 8085 Section
> 3.4.1, last bulleted paragraph above). This is possible for the client
> end of simple request-response protocols such as DNS or (with suitable
> initial handshakes that don't rely on CS=0) for both ends of a UDP
> application that sets up long-lived sessions between peers. It is not
> possible for a general server that does not know (and cannot establish
> during session setup) the source from which it will receive a packet.
>
> 4.) In order to cope with middleboxes that discard UDP datagrams with
> CS=0, a UDP application that uses FRAG+LITE with forced CS=0 SHOULD
> have a means to detect paths with high loss rates (RFC 6936 Section 5,
> objectives 6 and 7). This is possible only for applications that use
> long-lived flows.
>
> From my perspective, (1) and (2) are pretty much a wash between
> FRAG+LITE with CS=0 and the new alternative proposed in
> https://mailarchive.ietf.org/arch/msg/tsvwg/Wv--BLVMPAX6g5umok9BQsXAEGg:
> the new proposal provides a transport checksum of equivalent strength,
> and we still want application control over whether UDP fragmentation is
> enabled (which IMO should be on a per-port basis and should not happen
> by default). The new proposal does not disable the UDP checksum and so
> is not subject to (3). That is a big deal in my book, because (3) is a
> major burden. And (4) does not apply to the new proposal unless the
> application explicitly requests UDP CS=0, in which case it applies anyway.
>
> Mike