Re: Packet number encryption

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

hi Jana,

popping back up from the detailed engineering, thank you for this reframing.

I largely agree that this is the question; a few comments / friendly amendments on each point.

> On 7 Feb 2018, at 00:00, Jana Iyengar <[e-mail]> wrote:
> 
> I'm going to try a different attempt at moving towards convergence. Thinking about this some more, and picking up something that Mirja said way earlier in this thread, I think the following decomposition is useful.
> 
> 1. In the transport, all packet numbers start at 0, increasing monotonically. ACK frames carry these packet numbers, and therefore do not have to span large gaps and do not have to deal with increases in the size of the largest acked. Basically, no gaps are visible within the transport processing engine.
> 2. Before sending a packet on the wire, and before processing the packet, QUIC transforms the packet number with some function, replacing the visible packet number with the transformed value.
> 
> I think we can all agree that (1) is goodness.

Yep! (modulo the (completely separate and inconsequential for this discussion) question of whether packet numbers start at 0 or 1)

> A sender is also free to use packet numbers from non-contiguous spaces here FWIW, but that's entirely independent of what's visible on the wire. This helps me separate transport processing complexity from the rest of it, which I think is helpful.

+1.

> I think we are disagreeing on the precise properties we want from the transformation in (2). If we can agree on these properties, we can then figure out whether it's possible and how to construct such a transform. Here's a union of what folks are concerned about:
> 1. Packet number must be unlinkable across connection ID change (for migration.)

s/must/should endeavor to be/ -- true unlinkability is unattainable. The goal here is to make sure the packet number doesn't make it a lot easier.

> 2. Packet number must start at an arbitrary value, to avoid ossification of the first packet number.

Presuming that the model of ossification you're using here is "a middlebox vendor grabbing on to any bits it can find to distinguish quic from not-quic UDP traffic", then yes, this seems reasonable.

(There are an entirely different space of designs, which contains TCP, where the packet number itself is an implicit signal to prove to the path that a packet belongs to a flow beyond the five-tuple. In that case the arbitrary start would be necessary to have actual entropy for that signal. But we've abandoned this as a requirement in QUIC, in part due to the fundamental tension between avoiding linkability and proving things to devices on the path about the relationships among packets, i.e., "linkability" in other words.)

> 3. Some sequencing information -- a few bits of the packet number perhaps -- should be revealed (for monitoring. Number of bits TBD.)

This is the crux of the argument. On one side we have the risk of misuse and ossification (well, not ossification -- these bits are *meant* for the path -- rather the risk that we'll figure out later that we specified the wrong thing), on the other side we have the loss of visibility into how QUIC traffic interacts with the network as compared to TCP, with a side question of whether or not this visibility is really the transport layer's problem despite the evolution the practice of diagnostics and troubleshooting using TCP information.

If we can come to agreement on this question, everything else falls into place. I have my arguments here, but as you said, this subthread is not the place for them. :)

> 4. Any packet number transformation should not be compute intensive.

I'd say "should not have an inordinate marginal impact on performance", because otherwise you go down the rabbithole of relative complexity, but yeah.

Cheers,

Brian