回复: Can I set the UDP checksum to zero when running QUIC?
"Shihang(Vincent)" <shihang9@huawei.com> Sat, 16 March 2024 04:43 UTC
Return-Path: <shihang9@huawei.com>
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 6468DC14F60B for <quic@ietfa.amsl.com>; Fri, 15 Mar 2024 21:43:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.904
X-Spam-Level:
X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 pyfgfhQhuVHy for <quic@ietfa.amsl.com>; Fri, 15 Mar 2024 21:43:29 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A16EC14F5E0 for <quic@ietf.org>; Fri, 15 Mar 2024 21:43:29 -0700 (PDT)
Received: from mail.maildlp.com (unknown [172.18.186.231]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4TxT4x71bQz67nWm; Sat, 16 Mar 2024 12:42:57 +0800 (CST)
Received: from lhrpeml500002.china.huawei.com (unknown [7.191.160.78]) by mail.maildlp.com (Postfix) with ESMTPS id 326AF1413ED; Sat, 16 Mar 2024 12:43:26 +0800 (CST)
Received: from kwepemd200009.china.huawei.com (7.221.188.80) by lhrpeml500002.china.huawei.com (7.191.160.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Sat, 16 Mar 2024 04:43:25 +0000
Received: from kwepemd100007.china.huawei.com (7.221.188.221) by kwepemd200009.china.huawei.com (7.221.188.80) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.28; Sat, 16 Mar 2024 12:43:23 +0800
Received: from kwepemd100007.china.huawei.com ([7.221.188.221]) by kwepemd100007.china.huawei.com ([7.221.188.221]) with mapi id 15.02.1258.028; Sat, 16 Mar 2024 12:43:23 +0800
From: "Shihang(Vincent)" <shihang9@huawei.com>
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, Christian Huitema <huitema@huitema.net>, "Martin J. Dürst" <duerst@it.aoyama.ac.jp>, Martin Thomson <mt@lowentropy.net>
CC: "quic@ietf.org" <quic@ietf.org>
Subject: 回复: Can I set the UDP checksum to zero when running QUIC?
Thread-Topic: Can I set the UDP checksum to zero when running QUIC?
Thread-Index: Adp0X6nS+KJ2EcB6Q4Ws9l3n9uGVBQALeecAAAxYPQAAGcsLcP//oc+AgAAMgACAAEN6AIAAAPSA//uG1DA=
Date: Sat, 16 Mar 2024 04:43:23 +0000
Message-ID: <c3353017f62d47db9b6665b1c43b5a3d@huawei.com>
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> <03e4bfe5-6a4e-4b75-8a9a-80481b4f273c@erg.abdn.ac.uk>
In-Reply-To: <03e4bfe5-6a4e-4b75-8a9a-80481b4f273c@erg.abdn.ac.uk>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.126.200.88]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/RJE6xVIr7ZEznIlc4bDt77HVYH4>
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: Sat, 16 Mar 2024 04:43:33 -0000
I agree that the potential risk of disrupting legacy UDP applications outweighs the benefits of saving checksum computation. Thank you for your insightful discussion. Thanks, Hang -----邮件原件----- 发件人: Gorry Fairhurst <gorry@erg.abdn.ac.uk> 发送时间: 2024年3月14日 0:22 收件人: Christian Huitema <huitema@huitema.net>; Martin J. Dürst <duerst@it.aoyama.ac.jp>; Shihang(Vincent) <shihang9@huawei.com>; Martin Thomson <mt@lowentropy.net> 抄送: quic@ietf.org 主题: Re: Can I set the UDP checksum to zero when running QUIC? 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)