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

[Gorry Fairhurst <[e-mail]>]

On 13/03/2024 16:18, Christian Huitema wrote:
>
>
> 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
>
>
That all seems agreeable to me, thanks Christian,

gorry

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