Hi Boris, It's nice to see that you are working on hardware support for QUIC encryption. (BTW, I supervised Rebecka Alfredsson's master thesis project last year, where she used an NVIDIA BlueField 2 DPU for QUIC crypto offload.)
What I want to add is that you should consider multipath QUIC when you design your hardware. It affects the AEAD nonce generation. Regular, unipath, QUIC sets the top 34 bits of the packet number to zero when generating the nonce. In the upcoming multipath extension, the top 32 bits can be set to non-zero values. https://www.rfc-editor.org/rfc/rfc9001.html#name-aead-usage https://www.ietf.org/archive/id/draft-ietf-quic-multipath-03.html#name-packet-protection-for-quic- Best regards, Michael Eriksson ________________________________ From: Boris Pismenny <[email protected]><mailto:[email protected]> To: mailing-lists.ietf.quic Subject: Packet number encryption negotiation Date: Wed, 8 Feb 2023 09:25:07 +0100 (Central European Standard Time) Hello, I work on NIC hardware acceleration for NVIDIA, and we are looking into QUIC and DTLS1.3 acceleration. QUIC and DTLS employ packet number encryption (PNE) which increases security. At the same time, PNE significantly encumbers hardware acceleration as I’ll explain next. For hardware to encrypt the packet numbers, there are two options: 1. Feed the header back into the encryption machine after data has been encrypted. This means storing and forwarding data, higher implementation complexity, and greater bandwidth requirements on the single encryption machine. 2. Adding an additional unique pipeline stage dedicated for header encryption. As you may already know, this is not hardware friendly and for this reason many vendors will likely refuse to pay the cost of supporting this. But suppose a vendor does implement this feature, one problem still remains. PNE will still cause noticeable latency and performance degradation for high speed networks (think >400Gbps). Now, in certain use-cases, such as high performance computing, cloud computing, or data-center clusters—the security benefits of encrypting headers are marginal compared to the latency imposed by PNE. Would it be possible to consider letting these users negotiate to disable PNE and by doing so benefit (more) from encryption acceleration? Best regards, Boris
