Re: Getting to consensus on packet number encryption

[Mikkel Fahnøe Jørgensen <[e-mail]>]

Another observation point:

If there are so many concurrent paths in the host system that PNE matters,
then the cost of an additional keyed lookup is likely higher than PNE. You
can’t do much better than 40ns per lookup under ideal circumstances where a
minimum number of cache lines are hit, unless your working set is small.
Red-Black tree easily gets up to 2-400ns with current hardware. PNE is
below 30ns estimated - iff the decryption context is readily available.

The question is then, would avoiding PNE lead to additional lookups that
would not otherwise be required. Or, on the contrary would PNE lead to
additional lookups due to a separate encryption context. Lookup broadly
means fetching cache lines not otherwise required.


Kind Regards,
Mikkel Fahnøe Jørgensen


On 25 April 2018 at 12.14.35, Christian Huitema ([e-mail]) wrote:

On 4/23/2018 6:55 PM, Deval, Manasi wrote:

> I had brought up the issue with PNE several weeks ago as a barrier to
hardware offload. After further review, it looks like a hardware offload
can implement the PNE at a small cost.
>
> The implementation can modify current HW crypto accelerators to support
encrypting a buffer in the first pass and then encrypting packet number in
the 2nd pass as already discussed on this thread. The exact requirement
(header checksum, packet length encoding) is still in flux so there may be
some small variations depending on the accelerator and final algorithm
chosen for PNE. Future offload designs can do more to further reduce the
overhead.

Thanks for the information, Manasi. I have modified the wiki page
describing the PNE issues and alternatives to reflect this new data:
https://github.com/quicwg/base-drafts/wiki/Summary-of-the-PN-encryption-issues-and-alternatives.

With that new information, it appears that PR #1079 is superior to every
other alternative.

-- Christian Huitema