QUIC does allow for creating a custom version of the protocol but it should be registered with IANA. It is also possible to use unregistered version numbers for test purposes in closed environments, but tis hardly the case for released hardware. Weakening the security of official protocol versions through negotiation is likely not a good idea.
As to latency of hardware encryption: I’m not sure what unique pipeline stage means, but clearly some special attention is required for the header. Assuming we limit the discussion to AES encryption with block size 64, PNE works by sampling somewhere within the first AES block. We can assume there is enough data to sample because otherwise the packet is invalid so any random padding will do. You can precompute the AES encryption of the first block by encrypting zeroes so you have that encryption data before the packet data arrives - you should do that anyway for maximum throughput unless you are seriously constrained for memory. Potentially you can also precompute the packet number length and even the packet number itself, at least optimistically. Once the data arrives, you can immediately retrieve the plain text data segment of the first block - and sample the data needed for PNE encryption without delaying the encryption pipeline. Now you have the AES block and the clear text mask data, and you just need to XOR onto the packet being encrypted. You may need to double encrypt the packet number : both with the mask and with its AES block at its own location such that you can XOR it into place once the encryption stage signals the block is available. This will undo that packet number encryption by the encryption stage and apply the packet number encryption as intended. On caveat is that I do not remember how this affects the signature at the end of the packet, but I assume it does not include the encrypted version of the packet number, otherwise that would complicate things. This will not necessarily work for encryption schemes that do not rely on XOR for encryption, but you can limit negotiation to schemes that have hardware support without changing protocol version. As I recall, header encryption was a really hard nut to crack because any trivial encryption was either too weak or too complicated. Mikkel > On 8 Feb 2023, at 09.25, Boris Pismenny <borispisme...@gmail.com> wrote: > > 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: > > 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. > 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 >
