The idea of a trial ernabling zero checksum sounds a particularly
disruptive proposal for the Internet.
There are at three great reasons for requiring a checksum:
1. It provides some protection from misdelivery to the wrong port (aka a
differeny application) when a packet (or header is mangled in some way).
2. It provides some protection from corruption, a checksum is not that
good at this (TLS is better on the fields it protects) - but it can
certainly detect misaligned data copies, and such like.
3. It is needed in IPv6 for IP header protection.
In my opinion, 1 is the most ugly effect of setting a zero checksum - it
can result reduce the potential to detect unwanted insertion of data
into another socket/application... something that can be difficult for
legacy applictaions to detect. For backwards compatibility, please don't
use an automated way to find out what works for a particular app and
what does not!
That said, the IETF went to some effort to allow a very specific set of
exceptions - largely targeting the use of UDP as a shim within the
network (e.g,. between tunnel endpoints). Key implictaions are described
in RFC 6936. In these specific devices there may be no efficient way to
access the entire packet payload.QUIC receivers always process the
payload data.
If your IP address will only ever only every used for protocols that are
always robust to corruption (e.g. network tunnels), then check RFC 6936.
That not common for endpoints in general.
As Christian noted, I'd agree the EXTRA cost over
encryption/authentication is minimal, and since this is per-datagram
processing it could be offloaded to the line interface (or sometimes
combined with a checksum/copy) where the overall cost is negligable.
Hope that fills some of the background,
Gorry
On 13/03/2024 11:32, Martin J. Dürst wrote:
Hi everybody,
I'm a complete outsider, but it seems to me that the effort to decide
and remember where and when to use checksums and when not may quickly
get bigger than the effort to just checksum everything.
Regards, Martin.
On 2024-03-13 18:13, Shihang(Vincent) wrote:
Hi Christian,
The idea of trial is interesting. I wonder if the trial should be
done per path or per end host? Are you assuming some middleboxes will
mess up the NULL checksum UDP packets?
Thanks,
Hang
-----Original Message-----
From: QUIC <[email protected]> On Behalf Of Christian Huitema
Sent: Wednesday, March 13, 2024 12:51 PM
To: Martin Thomson <[email protected]>; [email protected]
Subject: Re: Can I set the UDP checksum to zero when running QUIC?
One the other hand, the cost of computing the checksum is tiny
compared to the cost of encrypting the packets. So there is a small
performance gain in not computing the checksum, compensate by the
potential gain of loosing compatibility.
If I were to do that, I would do some trials. Until the handshake is
complete, use the checksum. Then, send a trial packet with null
checksum. If the peer acknowledges it, then further packets can be
sent with null checksum. Redo the trial for each new path, or if
there are large number of packet losses. Basically, treat that the
same way we do PMTUD.
-- Christian Huitema
On 3/12/2024 3:57 PM, Martin Thomson wrote:
The question is more of a compatibility one than anything else.
What, if anything breaks if you do this?
As noted, there are contexts in which not computing the checksum
works. So I guess the conclusion is that nothing breaks, so go
ahead. QUIC doesn't depend on the checksum. All the cryptographic
bits of QUIC use far stronger and more reliable mechanisms.
On Tue, Mar 12, 2024, at 22:04, Shihang(Vincent) wrote:
Hi QUIC wg,
Since QUIC has strong encryption and integrity protection provided by
TLS 1.3. I wonder if the UDP checksum can be disabled(using UDP Zero
Checksum Mode https://www.rfc-editor.org/rfc/rfc6936 )to save the
computation just like in VXLAN(RFC7348
<https://datatracker.ietf.org/doc/html/rfc7348#autoid-12>).
Thanks,
Hang
