On Wed, Feb 8, 2023 at 10:16 AM 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.
Isn't the cost going to be one additional AES block+a small amount of routing+buffering the output packet (which you have to do anyway for pacing?) Yes, it's annoying that you have to back to the start of the packet to fill it in, but that seems relatively accommodate. I don't think it costs you bandwidth requirements, I think it costs 1 additional encryption+memory accesses. > > Adding an additional unique pipeline stage dedicated for header encryption. So I read the whole exchange downthread and I'm not quite sure what you mean by this. Is the idea that the hardware gets the packet in 16 byte lumps, encrypt each one, and separately has a dedicated encryptor for the encoded header that spits out the result along with the 2nd block into the downstream processing? So then the next thing is some sort of buffer that fast forwards the header when it is ready and then outputs the rest of the packet? This feels really similar to the first option/the optimization discussed below. > > 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). *spins the wheel of reincarnation* > > 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? It's only partially a security thing but also an anti-ossofication measure. > > Best regards, > > Boris > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
