Re: Packet number encryption negotiation

[Michael Eriksson <[e-mail]>]

On 2023-02-27 09:55, Boris Pismenny wrote:
Hi Michael,

On Fri, Feb 24, 2023 at 1:19 PM Michael Eriksson <[e-mail]<mailto:[e-mail]>> wrote:
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.)

Thanks, sounds like a cool project. It's worth saying that what we have in mind with crypto offload is based on an ASIC with limited promability, so any change to the AEAD is critical. This particular change to the AEAD doesn't seem to be a problem---IIUC, software associates CIDs with the corresponding path-ID and nonce, which can be even XORed together ahead of time to use the same hardware processing flow as single path QUIC.

Yep, the path ID could be XORed into the nonce in advance but then you need separate encryption HW state for each path. Another way is to attach the Path ID as packet metadata and only have one copy of the connection keys etc. Or maybe minimal per-path state that references common connection-level state such as the keys -- there are definitely different ways to do this.



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-

Thanks for the pointers, I've encountered multi-path QUIC on another discussion about QUIC offload (https://github.com/microsoft/quic-offloads/issues/9#issuecomment-1305823308<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-88d69ea0099e1120&q=1&e=e27b5977-1b4e-4703-957b-3236511a2976&u=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fquic-offloads%2Fissues%2F9%23issuecomment-1305823308>). IIUC, the main challenge with multipath will be to synchronize receive side NIC offloads when two NICs are being used in parallel to carry the same flow's packet number space.

There will only be separate packet number spaces for each path in the upcoming version of the multipath draft. Then I guess you will not have the problem you mention above. If you still would, why is this not a problem with regular unipath QUIC?

/me


________________________________
From: Boris Pismenny <[e-mail]><mailto:[e-mail]>
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