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

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

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
<https://tools.ietf.org/html/rfc8085#section-3.4.1> 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]
<https://tools.ietf.org/html/rfc6936#section-4> and with the usage
      requirements specified in Section 5 of [RFC6936]
<https://tools.ietf.org/html/rfc6936#section-5>.

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


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
<https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options-07#section-9>.

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