Re: Hardware acceleration and packet number encryption

[Ian Swett <[e-mail]>]

Thanks for the nice summary Jana.

As much as I'd love to have easier crypto HW acceleration, I've ended up
arriving at the same conclusion.  I don't want to bite off the work to do
proper multipath in QUIC v1, which I think is the only other reasonable
option of those Christian outlined.

If someone comes up with a way to transform packet number to make it
non-linkable, but doesn't have the downside of making hardware offload
difficult, then I'm open to it.  But we've been talking about this for 2
months without any notable improvements over Martin's PR.

Given we never talk about any issue only once in QUIC, I'm sure this will
come up again, but for the time being I think #1079 is the best option we
have.



On Wed, Mar 28, 2018 at 8:03 PM Jana Iyengar <[e-mail]> wrote:

> A few quick thoughts as I catch up on this thread.
>
> I spent some time last week working through a design using multiple PN
> spaces, and it is quite doable. I suspect we'll head towards multiple PN
> spaces as we consider multipath in the future. That said, there is
> complexity (as Christian notes). This complexity may be warranted when
> doing multipath in v2 or later, but I'm not convinced that this is
> necessary as a design primitive for QUICv1.
>
> We may want to creatively use the PN bits in v2, say to encode a path ID
> and a PN, for multipath. We want to retain flexibility in these bits going
> into v2. We've used encryption to ensure that we don't lose flexibility
> elsewhere in the header, and it follows that we should use PNE to retain
> flexibility in these bits as well. (Simplicity of design is the other value
> in using PNE, since handling migration linkability is non-trivial without
> it.)
>
> This leaves the question of HW acceleration being at loggerheads with the
> design in PR #1079. First, I expect that the primary benefit of
> acceleration will be in DC environments. Yes, there are some gains to be
> had in serving the public Internet as well, but I'm unconvinced that this
> is the driving use case for hardware acceleration. I understand that others
> may disagree with me here.
>
> AFAIK, QUIC has not been used in DC environments yet. I expect there are
> other things in the protocol that we'd want to change as we gain experience
> deploying QUIC in DCs. Spinning up a new version to try QUIC within DCs is
> not only appropriate, I would recommend it. This allows for rapid
> iterations internally, and the experience can drive subsequent changes to
> QUIC. It's what *I* would do if I was to deploy QUIC inside a DC.
>
> So, in short, I think we should go ahead with PR# 1079. This ensures that
> future versions are guaranteed the flexibility to change the PN bits for
> better support of HW acceleration or multipath or what-have-you.
>
> - jana
>
> On Mar 26, 2018 9:41 AM, "Christian Huitema" <[e-mail]> wrote:
>
>
> On 3/26/2018 8:20 AM, Swindells, Thomas (Nokia - GB/Cambridge) wrote:
>
> Looking at
> https://en.wikipedia.org/wiki/AES_instruction_set#Intel_and_AMD_x86_architecture
> it seems to imply a large range of server, desktop and mobile chips all
> have a CPU instruction set available to do AES acceleration and other
> similar operations (other instruction sets are also available).
>
> If we are considering the AES instructions then it looks like it is (or at
> least will be in the near future) a sizeable proportion of the public
> internet have it to be used.
>
>
> Certainly, but that's not the current debate. PR #1079 is fully compatible
> with use of the AES instructions. The issue of the debate is that the
> mechanism in PR #1079 required double buffering, first encrypt the payload,
> then use the result of the encryption to encrypt the PN. This is not an
> issue in a software implementation that can readily access all bytes of the
> packet from memory, but it may be an issue in some hardware implementations
> that are designed to do just one pass over the data.
>
>
> -- Christian Huitema
>
>
>
>