Re: Can I set the UDP checksum to zero when running QUIC?
Gorry Fairhurst <gorry@erg.abdn.ac.uk> Wed, 13 March 2024 16:22 UTC
Return-Path: <gorry@erg.abdn.ac.uk>
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 645C5C15108A for <quic@ietfa.amsl.com>; Wed, 13 Mar 2024 09:22:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, 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 oxJLWZ6UZt5x for <quic@ietfa.amsl.com>; Wed, 13 Mar 2024 09:22:31 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA32C1519B8 for <quic@ietf.org>; Wed, 13 Mar 2024 09:21:54 -0700 (PDT)
Received: from [192.168.1.130] (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id BA6D71B0010F; Wed, 13 Mar 2024 16:21:47 +0000 (GMT)
Message-ID: <03e4bfe5-6a4e-4b75-8a9a-80481b4f273c@erg.abdn.ac.uk>
Date: Wed, 13 Mar 2024 16:21:47 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Can I set the UDP checksum to zero when running QUIC?
Content-Language: en-GB
To: Christian Huitema <huitema@huitema.net>, "Martin J. Dürst" <duerst@it.aoyama.ac.jp>, "Shihang(Vincent)" <shihang9=40huawei.com@dmarc.ietf.org>, Martin Thomson <mt@lowentropy.net>
Cc: "quic@ietf.org" <quic@ietf.org>
References: <6e69606a9d9443668dda4ee33bf8f825@huawei.com> <0522153e-2492-46b9-a2ce-e29a479e79aa@betaapp.fastmail.com> <b492b220-605c-4066-a245-5a3871a2e689@huitema.net> <b3d6ff62ae4048228826bd1010c45e3c@huawei.com> <a87e315f-1d3b-4ec3-aa90-87b7af30343f@it.aoyama.ac.jp> <f58f35bf-2103-4cd8-9d7e-0a0ca8c3af3a@erg.abdn.ac.uk> <58f63c5f-63e2-45f5-a8a6-dd1f24ff6f45@huitema.net>
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Organization: UNIVERSITY OF ABERDEEN
In-Reply-To: <58f63c5f-63e2-45f5-a8a6-dd1f24ff6f45@huitema.net>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/wRvDkj3HHb-sw04FnnxoANCvz7c>
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 16:22:35 -0000
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 <quic-bounces@ietf.org> On Behalf Of Christian Huitema >>>> Sent: Wednesday, March 13, 2024 12:51 PM >>>> To: Martin Thomson <mt@lowentropy.net>; quic@ietf.org >>>> 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 >>>>> >>
- Can I set the UDP checksum to zero when running Q… Shihang(Vincent)
- Re: Can I set the UDP checksum to zero when runni… Martin Thomson
- Re: Can I set the UDP checksum to zero when runni… Christian Huitema
- RE: Can I set the UDP checksum to zero when runni… Shihang(Vincent)
- Re: Can I set the UDP checksum to zero when runni… Martin J. Dürst
- Re: Can I set the UDP checksum to zero when runni… Gorry Fairhurst
- Re: Can I set the UDP checksum to zero when runni… Christian Huitema
- Re: Can I set the UDP checksum to zero when runni… Gorry Fairhurst
- 回复: Can I set the UDP checksum to zero when runni… Shihang(Vincent)