Re: Getting to consensus on packet number encryption

[Brian Trammell (IETF) <[e-mail]>]

hi Mark, all,

IMO the decision as to whether packet number encryption is the right thing to do depends on the design we settle on for multipath, which I know is not very helpful with respect to "we need to make a decision now":

- If we end up with a multipath design with a single PN space across all subflows for a given MP connection -- a design which does have very nice properties -- then PN encryption seems to be mandatory to prevent trivial linkability across subflows.

- If we end up with a multipath design that provides multipath as layer 4.5 sitting atop multiple layer 4 connections (a la MP-TCP), then PN encryption is potentially nice to have for ossification prevention, but isn't very useful for much else AFAICT.

The fact that I believe the PN encryption question in V1 depends on a design choice in a V2 feature indicates that my opinion should logically be that PN encryption is not necessary for V1, but that we should work on improving what we have in #1079 to make it possible to easily offload to hardware, as a V2 feature.

Of course, it's more complicated than that, because isn't it always. Way more detail below (or just read draft-hardie-path-signals)...

Why encrypt packet numbers?
---------------------------

There are three broad justifications I've seen in the discussion to date for packet number encryption:

(1) "we're chartered to produce a protocol that's encrypted as much as operational concerns allow" -- like Mirja, I don't read the charter this way, though I acknowledge that might be a minority view. "Encrypt all the things" is a very nice organizing principle for work on QUIC, but without understanding (and coming to consensus to) the reasons *why* we want to encrypt the things, it is as useful a principle as "QUIC should be as blue as possible".

So we should talk about why we want to encrypt the PN:

(2) Ossification prevention. There seems to be rough consensus in the WG that exposing packet numbers will necessarily add them to the "descriptive invariants" -- i.e. parts of the wire image that we have not promised to keep the same but that will become difficult to change in future versions.

I believe this more on some days, and less on others.

On the one hand, most of the ossification that has happened to TCP's internal machinery happened because middleboxes could actually provide some perceived value to at least the person who approved the purchase, by understanding, reacting to, and modifying seq and ack numbers as well as tracking state. The QUIC packet number alone does not provide enough of a surface for middleboxes to do very much with it without breaking the protocol in ways that would become immediately apparent during testing.

On the other hand, naive attempts to apply TCP thinking to QUIC could lead to on-path breakage driven by PN inspection, and the built-in fallback to TCP could mask some of the issues this causes. (cf. Happy Eyeballs, which makes IPv6 migration less disruptive, also makes it less successful -- something like 10% of the Alexa top million sites that "support IPv6" from a DNS standpoint don't really accept connections).

Certainly, PN encryption is the conceptually simplest way to obfuscate PN behavior, if we decide that it is necessary for us to obfuscate the PN in V1 in order to preserve the ability to deploy PN encryption in V2.

(3) Linkability prevention. IMO this is only really relevant in a multipath situation, where the multipath design uses a single packet number space across all subflows (as noted above). Unintentional (on the part of the client) NAT rebinding in the presence of a server CID is already trivially linkable, and not particularly sophisticated traffic analysis in the middle can build small anonymity groups for migration based on timing alone, so PN encryption doesn't help much in the case that a rebinding might happen without client permission. (#include "brian_is_a_traffic_analysis_nihilist.md")

I actually find a fourth, more abstract reason more compelling than any of these:

(4) The path should only get to see stuff that's explicitly meant for the path. The packet number, with its present semantics, has no explicit utility for on-path devices. (It might have *implicit* utility for on-path devices, which I address below.)


Why not encrypt packet numbers?
-------------------------------

There are similarly two broad justifications for not encrypting packet numbers:

(1) Performance and scalability. Encrypting and decrypting packet numbers takes additional CPU, and two-pass encryption lends itself poorly to encryption offload.

It's difficult to make judgements based on this without a more detailed performance analysis. There are lots of things that might make QUIC slow -- an assumption in kernel UDP interfaces that UDP doesn't have to be fast, for instance -- and in the spirit of engineering we should address these in the order of their performance impact, based to the extent possible on real measurements of actual prototypes of the mechanisms proposed.

I recognize the tension between QUIC's design principle of transport-as-continuous-experiment and the desire of people who make chips to have a draft protocol they can implement offload for as early as possible, and the tension between the flexibility that userspace implementation affords and the restrictions on what is easy to do in hardware.  I also recognize that some of the people who would deploy QUIC might not if it means they have to scale their backends multiplicatively due to increased CPU requirements of a non-offloadable protocol. Hence I think we should work to make something like 1079 more offloadable.

(2) Utility to on-path devices. The path can use the packet number for various forms of classification (i.e., "is this probably QUIC?") and state tracking ("does this look like a valid packet for a flow I know about?"), as well as passive measurement and diagnostic purposes (i.e., for one-point upstream loss and reordering measurement, as well as for rejecting loss and reordered spin edges with a single spin bit).

I'm not sure any of these are really good uses of a cleartext packet number. In each of these cases a cleartext packet happens to share some properties with the ideal signals for each particular task.

We should decide for each of these cases whether they are important, then design specific signals for each of them. The spin bit + VEC discussed in London for passive latency measurement (and to be described in an individual draft we'll submit shortly for consideration for adoption) is one example of this. Passive RTT measurement can also be achieved with a cleartext PN and PN echo, but the spin+VEC has superior measurability characteristics as well as superior efficiency. Examination of other uses might lead us to add a signal back to the wire image that counts up kind of like a packet number, but need not necessarily be tied to the number the transport uses for its own internals.

(Or, as above, tl;dr, see draft-hardie-path-signals)

Cheers,

Brian


> On 4 Apr 2018, at 06:58, Mark Nottingham <[e-mail]> wrote:
> 
> Hi everyone,
> 
> The editors have told your chairs that this issue is starting to block progress on other aspects of QUIC. Coming to consensus on it soon (i.e., before Stockholm, if possible) would be good.
> 
> It looks like this thread has come to a natural pause. Reading through it, I think we agree there are some unpleasant tradeoffs here, but so far we have only one concrete proposal -- PR#1079.
> 
> My AU$.05 - While we're chartered to produce a protocol that's encrypted as much as operational concerns allow, and that privacy is a natural extension of that (especially in light of RFC7258 and RFC6973), there is no *requirement* that we produce a protocol that is able to be accelerated by hardware.
> 
> That being the case, I think we need to ask ourselves if we believe that inclusion of PR#1079 will significantly inhibit deployment of the protocol. Based on the discussion so far, that doesn't seem to be the case, but I'd be interested to hear what others think.
> 
> If we can get to consensus to incorporate the PR, and folks come back later with a more hardware-friendly replacement that doesn't change the Invariants or increase linkability, I suspect the WG will be amenable to that.
> 
> What do folks think?
> 
> Cheers,