Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-31.txt

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

On Wed, Mar 6, 2024 at 8:18 AM Tom Herbert  wrote:
> The implication is that we can use an alternate CRC when the UDP
> checksum is either not used or considered too weak. I think it's also
> implied that any alternate to UDP checksum would need meet the same
> salient requirements as UDP checksum which are:
>
> 1) Use of the checksum or CRC is optional only by the sender not the
> receiver. From RFC1122: "Unlike the TCP checksum, the UDP checksum is
> optional; the value zero is transmitted in the checksum field of a UDP
> header to indicate the absence of a checksum."
> 2) If a checksum or CRC is received then the receiver MUST either
> validate that it is correct or drop the packet: From RFC1122 "If a UDP
> datagram is received with a checksum that is non-zero and invalid, UDP
> MUST silently discard the datagram."

The requirements that you cite certainly apply to the UDP checksum, but
where does 1122 or any other IETF standard say "or CRC"?

Admittedly, the way that we have traditionally written our
specifications creates that expectation. But an expectation is not
necessarily a requirement. As currently specified, APC (and AUTH,
when it is completed) will allow mutually consenting endpoints to
use a stronger integrity check (or authentication). That makes them
useful building blocks. And there is something to be said for having
them be incrementally deployable. I recall a long-ago comment of Michael
Richardson's that it was a historic mistake for the IP AH specification
to require mandatory drop for authentication failures because doing so
inhibited incremental deployment.

Mike Heard