Re: Packet number encryption negotiation

[Boris Pismenny <[e-mail]>]

Hi Michael,

On Fri, Feb 24, 2023 at 1:19 PM Michael Eriksson <
[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.


>
> 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).
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.


>
> Best regards,
> Michael Eriksson
>
> ------------------------------
> *From:* Boris Pismenny <[e-mail]> <[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
>
>
>