Re: Getting to consensus on packet number encryption

[Kazuho Oku <[e-mail]>]

Manasi, thank you for the update.

In addition to the points that Jana and Ian made, it would be great if
you could provide us some estimation on if using different keys for PN
encryption and payload encryption affects HW offload performance /
portion of existing hardware that can support this form of encryption.

On https://github.com/quicwg/base-drafts/pull/1079#issuecomment-382007477,
Antoine has recently suggested that the PNE scheme proposed in #1079
can be tweaked to use the same key for encrypting the PN and the
payload (they will use same key but different nonces).

This is minor to the points made by Jana and Ian, but I think it would
be something good to know to make a decision.

2018-04-24 8:22 GMT+09:00 Ian Swett <ianswett=[e-mail]>:
> Yes, thanks for the update.
>
> Can you estimate the portion of existing hardware(that supports TCP crypto
> offload) which could support crypto offload for QUIC with PNE vs without
> PNE?
>
> On Mon, Apr 23, 2018 at 6:49 PM Jana Iyengar <[e-mail]> wrote:
>>
>> Thanks for the update, Manasi. In practice, can you state what this small
>> cost is? Is it the second crypto pass, or are there other deployment costs
>> that you are thinking about?
>>
>> On Mon, Apr 23, 2018 at 10:55 AM, Deval, Manasi <[e-mail]>
>> wrote:
>>>
>>> Hi All,
>>>
>>> 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.
>>>
>>> This re-opens the issue of crypto offload in the context of other
>>> offloads. There is another thread talking about the offload in context of
>>> segmentation. I'll respond to that thread separately.
>>>
>>> Thanks,
>>> Manasi
>>>
>>>
>>> -----Original Message-----
>>> From: QUIC [mailto:[e-mail]] On Behalf Of Christian Huitema
>>> Sent: Wednesday, April 18, 2018 9:38 AM
>>> To: Mark Nottingham <[e-mail]>
>>> Cc: [e-mail]
>>> Subject: Re: Getting to consensus on packet number encryption
>>>
>>>
>>>
>>> On 4/18/2018 1:09 AM, Mark Nottingham wrote:
>>> > Thanks Christian; that's extremely helpful (and considering that I was
>>> > about to embark on the same task, but do a much worse job, I'm especially
>>> > appreciative).
>>> >
>>> > Everyone please have a read and direct your comments back here.
>>> >
>>> > One aspect that still hasn't been made clear AFAICT -- you say:
>>> >
>>> > """The process requires two passes, fetching some output of the
>>> > encryption to seed the PN encryption. This is problematic for hardware
>>> > implementations that typically don't buffer the output for further
>>> > access."""
>>> >
>>> > .... and then later:
>>> >
>>> > """Single pass, thus mostly implementable in hardware if we assume that
>>> > the PN encryption/decryption can be done in software."""
>>> >
>>> > Having a bit more context about the hardware implementation limitations
>>> > here would be extremely helpful. Specifically, is "problematic" one of:
>>> >
>>> > * "More difficult for existing hardware (e.g., without firmware
>>> > updates, etc.)"
>>> > * "Impossible for existing hardware, but possible for bespoke hardware"
>>> > * "Impossible in any hardware"
>>> > * Prohibitively expensive for current/future hardware
>>> > * Something else?
>>>
>>> I tried to express the issue in my own words, based on discussions in
>>> this list. But as I said, this is a Wiki. People with more hands-on
>>> experience on hardware acceleration would be welcome to add a small section
>>> describing the issue with hardware implementations.
>>>
>>> -- Christian Huitema
>>>
>>
>



-- 
Kazuho Oku