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

Christian Huitema <huitema@huitema.net> Wed, 13 March 2024 04:50 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C69C3C14EB17 for <quic@ietfa.amsl.com>; Tue, 12 Mar 2024 21:50:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OB_t-avXuHW for <quic@ietfa.amsl.com>; Tue, 12 Mar 2024 21:50:54 -0700 (PDT)
Received: from se02.mfg.siteprotect.com (se02.mfg.siteprotect.com [64.26.60.165]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BB26C14F60B for <quic@ietf.org>; Tue, 12 Mar 2024 21:50:51 -0700 (PDT)
Received: from smtpauth02.mfg.siteprotect.com ([64.26.60.151]) by se02.mfg.siteprotect.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1rkGZh-00HK1s-V7; Wed, 13 Mar 2024 00:50:49 -0400
Received: from [192.168.1.102] (unknown [172.56.200.68]) (Authenticated sender: huitema@huitema.net) by smtpauth02.mfg.siteprotect.com (Postfix) with ESMTPSA id 4TvdPH6dHvz2YQR6N; Wed, 13 Mar 2024 00:50:43 -0400 (EDT)
Message-ID: <b492b220-605c-4066-a245-5a3871a2e689@huitema.net>
Date: Tue, 12 Mar 2024 21:50:42 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Can I set the UDP checksum to zero when running QUIC?
Content-Language: en-US
To: Martin Thomson <mt@lowentropy.net>, quic@ietf.org
References: <6e69606a9d9443668dda4ee33bf8f825@huawei.com> <0522153e-2492-46b9-a2ce-e29a479e79aa@betaapp.fastmail.com>
From: Christian Huitema <huitema@huitema.net>
Autocrypt: addr=huitema@huitema.net; keydata= xjMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1RmvN J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsKWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAzjgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB8J+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH
In-Reply-To: <0522153e-2492-46b9-a2ce-e29a479e79aa@betaapp.fastmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Authentication-Results: mfg.siteprotect.com; auth=pass smtp.auth=huitema@huitema.net
X-Originating-IP: 64.26.60.151
X-SpamExperts-Domain: mfg.outbound
X-SpamExperts-Username: 64.26.60.150/31
Authentication-Results: mfg.siteprotect.com; auth=pass smtp.auth=64.26.60.150/31@mfg.outbound
X-SpamExperts-Outgoing-Class: ham
X-SpamExperts-Outgoing-Evidence: Combined (0.26)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT+ZzqP4MtzbmhC9FWccQeEGPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5yDp6ermGYZsAFCwS37qS9XSAQmXTtozqyGj71is2hdtIk7 bUF9UdO+g20nehFCqx5pVmT40eaKdcIFF7//lyq1WmuNA8WTybi1JN85FSnfKfyrBBzCRb2oe4JC Nd2sOpcoAqH4ZGMNlhk2Ueq2ABMeJ6ED5FlOjdPKZAPYAfsdcyvnZuXOpOBFXqmxiAPmdi+9X1iM qrT9gM9RcCk/xERud+EVUVRGb9HvMpHo1y1/NlHuAq4k7PqG9M5idz7joR7ndEL8IbXBpRiMfP45 Wz78wlk3IikaAYYay6zwzan8jJM4FJK5OR3dA6AwcnrK6eluxYvH2diC53wrDh3bCBPDF5WZp3Aj doRkErSrWMfJQFDPwyNmn3r2DRb/lAfl4dz72fuC0vmH1NtLfLgbXr/6RV16qVXFRYQ6YJ5xnfU7 8KXbhVB+eMaMyF2AvwDuK7lIVHEcOUNwMslEo7w3btjdPWuTEx8Bzabre3XaZwoie0G6U+GZxkal SNeoyQ5z7ZjymM4V+dYvw3zgaX5MC+SYhClGQqBaLo/4e5RWTejdpMF40MajfsURz8L4dmQLKmUn 3G3h4kq+s6OnDaq3gbOoLp4HUmOv3VPR5LKwIGE/VifImdlgAxsZswu7t0PKWPmf2RBXYH5f4IOE 2j1G8UoUYv9nF9j55FIOPtJO/ttWCz+4P7/NsNT7JHCvOnHPp4Pdn+cousT5+gFGAcOaNJ6lTAsG qvlS8XowgRKLibuK9E9EUDwTCfbSvjFHgHqV661IyIoo+bYQoT2vlEpv6c1NlSI+4YjCluQ4IZMf G/oQ7m8yuzZDjNtt/NYVA5JIEhQOUR13T2x+O3m5aHexa952xlGZ460a0GbfQIoDrlhmJ36m+UeF XprlCOm3BAEbJtA3bcGTeZ0urnut+upIIpMExDM3qyX0GvVAGCrIBFfKftNuxPWpxL5GHCQBH7aS 8gWEFogaKRwR7VEvfIUJYZaqCAkqxWp6z91tiLWeLq9oaPXS1+qgaVt1ORMtpYIBctq+zrhM0/jh LR9EiE4MfGZkMS+4ayUpOtEhdxekWDmK9g==
X-Report-Abuse-To: spam@se02.mfg.siteprotect.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/mj855WW62IGcnplQU4MWC1JLKpQ>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Mar 2024 04:50:57 -0000

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
>