Re: Hardware acceleration and packet number encryption

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

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