Re: Can I set the UDP checksum to zero when running QUIC?

[Christian Huitema <[e-mail]>]

On 3/13/2024 5:16 AM, Gorry Fairhurst wrote:
> The idea of a trial ernabling zero checksum sounds a particularly 
> disruptive proposal for the Internet.

As Martin Dürst says, the complexity is probably not worth the gain.


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

Yes. The cryptographic checksum will protect the intended receiver, but 
undetected errors in the IP/UDP header could result in delivering 
encrypted bytes to unexpected applications. Kind of like fuzzing them, 
which may be bad.

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

We are speaking of the 16 bytes cryptographic checksum in QUIC packets, 
same algorithms as the TLS checksum. I would expect it to provide more 
than "some" protection. If the packet decrypts and authenticate 
properly, then there is a very high assurance that it is exactly what 
the sender sends.

> 3. It is needed in IPv6 for IP header protection.

That's a true argument. And it rubs one of the raw parts of QUIC: there 
is no guarantee that the IP header seen by the receiver is the same as 
seen by the sender. The packet encryption is QUIC deliberately does not 
verify anything like the "pseudo header" of TCP.

QUIC does that so it can detect NAT rebinding and react properly. TCP 
does not. To support going through NAT, TCP requires that NAT 
"recompute" the TCP checksum -- which has very much the same risks as 
not having an end-to-end checksum that includes the pseudo-header.

> 
> 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!

Yes, the risk is a form of "fuzzing legacy UDP applications".

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

I agree with Martin Dürst's argument that the complexity is probably not 
worth the limited gains.

That discussion made me think again about the need for some form of 
pseudo-header protection in QUIC. The current state supports NAT 
traversal and NAT rebinding, which is good, but it allows attacks by on 
path observers that can forward copies of good packets with a spoofed IP 
header, which is not so good.

-- Christian Huitema



> 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 <[e-mail]> On Behalf Of Christian Huitema
>>> Sent: Wednesday, March 13, 2024 12:51 PM
>>> To: Martin Thomson <[e-mail]>; [e-mail]
>>> 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
>>>>
>