Re: Getting to consensus on packet number encryption

[Ian Swett <[e-mail]>]

It has been, and I'm personally supportive of it, because I believe it'll
be useful for datacenter QUIC use cases.

But the WG has to decide:
 1) Is it allowable to disable PNE?
 2) What the mechanism is?  ie: Unilateral via TransportParams or
negotiated via an extension or ?

On Wed, Apr 25, 2018 at 6:01 PM Mike Bishop <[e-mail]> wrote:

> I think that’s been suggested before, though we’d need to sort out the
> details of what that looks like.  I don’t have a particular design in mind.
>
>
>
> *From:* Ian Swett [mailto:[e-mail]]
> *Sent:* Wednesday, April 25, 2018 12:57 PM
> *To:* Mike Bishop <[e-mail]>
> *Cc:* Christian Huitema <[e-mail]>; Deval, Manasi <
> [e-mail]>; Mark Nottingham <[e-mail]>; IETF QUIC WG <
> [e-mail]>
> *Subject:* Re: Getting to consensus on packet number encryption
>
>
>
> Hi Mike,
>
>
>
> To clarify, are you suggesting adding a way to disable packet number
> encryption via negotiation in the v1 spec as well as adopting #1079?  Or
> would the choice of whether PNE is to be used unilateral, such as a
> transport param?
>
>
>
> On Wed, Apr 25, 2018 at 3:54 PM Mike Bishop <[e-mail]> wrote:
>
> Yes -- it seems that the biggest objection to #1079 was the difficulty in
> hardware implementation.  If we're hearing that hardware implementation is
> feasible at a reasonable cost, then I think we might have a winner.
>
> The CPU cost for a software implementation is still worth considering, and
> an option to not encrypt is probably reasonable to limit that burden for
> implementations / use cases that don't care.
>
> -----Original Message-----
> From: QUIC <[e-mail]> On Behalf Of Christian Huitema
> Sent: Wednesday, April 25, 2018 3:14 AM
> To: Deval, Manasi <[e-mail]>; Mark Nottingham <[e-mail]
> >
> Cc: [e-mail]
> Subject: Re: Getting to consensus on packet number encryption
>
> 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
>
>