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 <[email protected]> 发送时间: 2024年3月14日 0:22 收件人: Christian Huitema <[email protected]>; Martin J. Dürst <[email protected]>; Shihang(Vincent) <[email protected]>; Martin Thomson <[email protected]> 抄送: [email protected] 主题: 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 <[email protected]> On Behalf Of Christian Huitema >>>> Sent: Wednesday, March 13, 2024 12:51 PM >>>> To: Martin Thomson <[email protected]>; [email protected] >>>> 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 >>>>> >>
