Re: [tsvwg] Intdir early review of draft-ietf-tsvwg-udp-options-19

[Tom Herbert <[e-mail]>]

On Wed, Feb 15, 2023 at 2:55 PM C. M. Heard <[e-mail]> wrote:
>
> On Tue, Feb 14, 2023 at 9:50 AM Tom Herbert wrote:
> > On Mon, Feb 13, 2023 at 3:08 PM C. M. Heard wrote:
> > > Section 7 of the draft currently says:
> > >
> > >    Like the UDP checksum, the OCS is optional under certain
> > >    circumstances and contains zero when not used. UDP checksums can be
> > >    zero for IPv4 [RFC791] and for IPv6 [RFC8200] when UDP payload
> > >    already covered by another checksum, as might occur for tunnels
> > >    [RFC6935]. The same exceptions apply to the OCS when used to detect
> > >    bit errors; an additional exception occurs for its use in the UDP
> > >    datagram prior to fragmentation or after reassembly (see Section
> > >    9.4).
> > >
> > > If this guidance is too slender, how should it be improved?
> >
> > Mike,
> >
> > The casual reference to RFC6935 is a good example of why this text is
> > insufficient. RFC6935 and RFC6936 were created to allow UDPv6 packets
> > to have a zero checksum. The UDP checksum was required in IPv6
> > (RFC2460) because, unlike IPv4, the IPv6 header doesn't contain a
> > header checksum; the UDP checksum includes the pseudo header that
> > covers the IPv6 address. So the UDPv6 checksum is needed as an
> > integrity check of the IPv6 addresses, and the primary risk of using
> > CS=0 with UPDv6 is the potential for misdelivery when addresses are
> > corrupted. That is the primary consideration of RFC6935 and RFC6936.
> > Note that it is a misnomer that those RFCs allow a zero UDPv6 checksum
> > for all packets, in fact it is a narrowly defined exception applicable
> > to tunnel protocols under specific circumstances. Also note, in
> > RFC8086 (GRE over UDP), it still took three pages of requirements to
> > show how the specific protocol meets the requirements of RFC6935 and
> > RFC6936. IMO an offhand statement that the exceptions of RFC6935 and
> > RFC6936 are applicable for a new protocol is trite.
>
> You have a point here.
>
> > While the risk RFC6935 and RFC6936 is packet misdelivery, the risk of
> > UDP options is misinterpretation of protocol in a packet. UDP options
> > present an entirely different problem and the means to address it will
> > be different. The UDP checksum is completely independent and has no
> > correlation to the bits of the surplus space, the UDP checksum does
> > not cover the surplus space and neither is there any coverage if "UDP
> > payload is already covered by another checksum".
>
> That's not entirely true. In the case of a reassembled UDP datagram,
> the entire datagram and any trailing options will have been covered
> by the OCS of the UDP fragments, if it is present. For that reason, it
> it is perfectly reasonable to omit both the UDP checksum and OCS in the
> reassembled datagram -- as noted in this text from Section 7:
>
>    an additional exception occurs for its use in the UDP datagram prior
>    to fragmentation or after reassembly (see Section 9.4).
>
> The considerations would be different of course if OCS on the UDP
> fragments were not present ... I will have more to say about this below.
>
> > So the "The same
> > exceptions apply to the OCS" are not valid since the exceptions refer
> > to the UDP checksum which has different properties and different
> > risks. Without a proper code point, the protocol of the surplus space
> > needs to be determined solely based on the contents of the space, not
> > the UDP checksum nor anything else in the packet, and any means of
> > this determination is probabilistically correct. The probability of
> > misinterpretation with a checksum is 1/65,536 which is presumably
> > sufficient. If the idea is to forgo the checksum, then one would
> > expect a quantitative analysis of both the probability of
> > misinterpretation and the risks of misinterpretation.
> >
> > That being said, I see no zero value in making the checksum optional.
> > Aside from its critical role in validating the surplus is indeed UDP
> > options, UDPv6 packets are required to have a non-zero checksum so the
> > OCS is required for all of IPv6 (again RFC6935 and RFC6936 are narrow
> > exceptions). Furthermore, TCP, the original transport layer protocol
> > with options, and IPv4 have had a checksums since the beginning and we
> > don't see people complaining about the performance of those.
>
> Actually, I am mostly in agreement with this point ... much of the
> motivation for UDP with CS=0 has faded as hardware checksum offload has
> become a thing. And even back in RFC 1122 (October 1989) we see:
>
>             DISCUSSION:
>                  Some applications that normally run only across local
>                  area networks have chosen to turn off UDP checksums for
>                  efficiency.  As a result, numerous cases of undetected
>                  errors have been reported.  The advisability of ever
>                  turning off UDP checksumming is very controversial.
>
> Situations where we still see what IMO is legitimate resistance to UDP
> checksums -- and which is part of what motivated RFC 6935 and RFC 6936
> -- are implementations that have limited access to packets, i.e., that
> have full access to the first N bytes of the packet but not to the
> remainder. In such instances tunnelling protocols can insert UDP headers
> but cannot calculate a full UDP checksum. It is conceivable that such a
> a tunnel could implement UDP fragmentation but, lacking access to the
> whole packet and so could not compute the OCS for the fragments. In that
> case the inner packet, whatever it is, would have its own headers and
> trailers, which should be completely covered by appropriate transport
> checksum(s) -- e.g., by the TCP checksum, if it is a TCP segment, or
> by the UDP checksum and OCS, if it is a UDP datagram with UDP options.
> In this case the outer UDP fragments would legitimately have UDP CS=0
> and OCS=0, by obvious extension of RFC 6935 and RFC 6936.

Mike,

Okay, that may be a valid argument to make the surplus checksum
optional when the UDP length is 8 and it's a UDP tunnel, but to
require it in all other cases. The "tunnel" aspect of the requirement
would be that described in RFC6935 and RFC6936, however note that the
requirement would need to apply to IPv4 tunnels also since the risk of
misinterpretation is present in both UDPv4 and UDPv6 but the
misdelivery risk of RF6935 and RFC6936 is specific to IPv6.

Tom

>
> On Wed, Feb 15, 2023 at 8:49 AM Gorry Fairhurst <wrote:
> > I for one also think that last para on whether OCS needs to be required
> > in all cases is something that needs to be considered carefully.
>
> There may be a case to be made for tightening the constraints on when
> UCP CS=0 is acceptable, but I do not think that it should be banned
> outright. There is a case to be made that it is appropriate and useful
> under certain circumstances, some of which are discussed above.
>
> On the other hand, there are two very practical reasons for requiring
> OCS <> 0 when UDP CS <> 0. First, as noted in the draft, it bypasses
> an annoying but apparently common middlebox error (see
> https://datatracker.ietf.org/meeting/103/materials/slides-103-maprg-a-tale-of-two-checksums-tom-jones),
> and second, it greatly facilitates hardware checksum offload (see
> https://mailarchive.ietf.org/arch/msg/tsvwg/9_1YWp-TApI9mcCuia8U6jfCwTA/).
>
> So I see coupling the two as quite logical.
>
> Mike Heard