Re: Hardware acceleration and packet number encryption

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

BTW: segmented packet numbers also provides convenient support for
multi-core packet generation because each core could have its own segment,
even on the same path. It can encrypt without conflict with peer cores on
the same connection and without inducing false packet reordering. As
mention in the github issue a sender can also alternate between segments to
defend against optimistic ACK without introducing packet gaps. Thus, all
gaps are losses or reodering.

On Sat, Mar 24, 2018 at 1:57 PM Mikkel Fahnøe Jørgensen <[e-mail]>
wrote:

>
> see reply below
>
> On Sat, Mar 24, 2018 at 1:19 PM Christian Huitema <[e-mail]>
> wrote:
> ...
>
>>  packet number encryption as specified would make
>> acceleration of Quic difficult to implement on Intel's hardware. She was
>> trying to convince us that privacy is an unattainable goal, and that we
>> should just as well ditch the linkability requirement in order to
>> facilitate hardware acceleration.
>
>
> I also believe that privacy is a wild goose chase. There is no reason to
> expose more
> necessary, but we risk limiting the protocol design more than it is worth.
>
> Even without HW accellaration, modifying a buffer in-place can affect CPU
> cache
> performance and synchronization on multi-core systems, and it adds latency
> - which
> might be small in todays typical use case, but not necessarily in special
> cases or in the future.
> Crypto might get faster, but possibly by adding parallelism with higher
> latency and packet number
> encryption cannot be parallized.
>
>
>> Using separate packet number for each path would prevent linkability and
>> facilitate acceleration, but it makes the protocol and the software
>> significantly more complex. It requires using different keys or IV for
>> different paths, and it also require management of several sequence
>> number spaces.
>
>
> This is largely what I have proposed in Segmented Packet Numbers
> https://github.com/quicwg/base-drafts/issues/1105
>
> The idea is that the packet number itself is larger than the wire
> transmission. The high bits are hidden from the packet header
> but are included internally and in ACK frames (using some varlen
> encoding). This will naturally sort ACK's per path and give
> a largest ACK'ed per path. There would be no total ordering which might be
> a problem with some designs relying on
> "everyting send before" such as new path id's. It wold allow for packet
> numbers larger than 64 bit. In ACK only the first packet number in a block
> is sent explicitly so there is a natural compression.
>
> Yes, it complicates the design slighty but it gives you a lot of automatic
> per path ACK RTT data and sidesteps the issue with encryption
> and also provides easy monitoring to middleware - data that they could
> infer less reliably on their own in most cases, so no loss of privacy.
>
> I like the simplicity of packet number encryption but due to how it needs
> to be implemented I'm no longer believing that this is a great idea.
>
> Mikkel
>