Subject: what was yesterday's packet number decision?

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Tue, 23 Jan 2018 16:04:18 +0100

Greetings, all,

I've reviewed the notes of the discussion on yesterday's greasing discussion at the interim, and while there's not *quite* enough context there for me to figure out what was decided, I think this is the proposal:

(1) Packet numbers in both long and short headers should no longer have the property that they monotonically increase

(a) on the theory that an intermediary that is attempting to lazily classify QUIC will may classify future discontinuity in this packet number space as not-QUIC; and

(b) because packet number monotonicity increases flow linkability over migration events that the sender does not know about, and we would like to avoid these.

Is this the scope of the new PR Martin has volunteered to send?

Thanks, cheers,

Brian

---

From: "Lubashev, Igor" <[email-masked]>
Date: Tue, 23 Jan 2018 15:18:27 +0000

> (b) because packet number monotonicity increases flow linkability over migration events that the sender does not know about, and we would like to avoid these.

Would not the Connection ID give it away in these cases anyway?  Cases when the sender does know about migration events may fare better, if the sender has received NEW_CONNECTION_ID in advance of the migration event.

- Igor

-----Original Message-----
From: Brian Trammell (IETF) [mailto:[email-masked]] 
Sent: Tuesday, January 23, 2018 10:04 AM
To: QUIC WG <[email-masked]>
Subject: what was yesterday's packet number decision?

Greetings, all,

Thanks, cheers,

Brian

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Tue, 23 Jan 2018 17:12:34 +0100

> On 23 Jan 2018, at 16:18, Lubashev, Igor <[email-masked]> wrote:
> 

Yeah, that's part of why I'm confused by the notes.

 I think the underlying requirement here is to give an endpoint (defined either as "the sender of a direction of a QUIC flow" or more explicitly as "the client") some measure of control over how linkable its packets are. Not using CID at all, and obfuscating the packet sequence, increases the complexity of flow linkage during involuntary migration.

(I say "increases the complexity" as opposed to "reduces linkability" because, as a measurement geek, I'm deeply pessimistic about the ability to eliminate linkability of packets sent by the same sender. After you have added a runtime requirement to keep some amount of per-flow state in order to link packets to a flow, any additional complexity in packet number obfuscation only serves to increase the amount of work to design an algorithm for linking packets, i.e., it increases the number of masters' and/or doctoral degrees awarded to people who work on solving the problem of linking QUIC flows.)

Cheers,

Brian

---

From: Christian Huitema <[email-masked]>
Date: Tue, 23 Jan 2018 11:42:44 -1000

On 1/23/2018 6:12 AM, Brian Trammell (IETF) wrote:
> (I say "increases the complexity" as opposed to "reduces linkability" because, as a measurement geek, I'm deeply pessimistic about the ability to eliminate linkability of packets sent by the same sender. After you have added a runtime requirement to keep some amount of per-flow state in order to link packets to a flow, any additional complexity in packet number obfuscation only serves to increase the amount of work to design an algorithm for linking packets, i.e., it increases the number of masters' and/or doctoral degrees awarded to people who work on solving the problem of linking QUIC flows.)\

In addition to linkability, there is an AEAD issue. We MUST guarantee
that the same packet sequence number will not be used twice with the
same key. One class of solution is to use different encryption keys per
connection ID. We looked at that, and the sense of the room was that it
was very complex. But if we use the same encryption context across
multiple connection ID, the simplest way to guarantee that packet
sequence numbers don't repeat on multiple connection is to use a "global
sequence". And if you do that, you have a really big issue with
linkability, and the easiest way to solve that is to encrypt the packet
sequence number.

Encrypting the packet sequence number also has the nice property of
ensuring that non invariant bits cannot be easily guessed by
middle-boxes. So, it prevent ossification, and will allow us to later
switch to for example var length encoding.

Another nice property of encrypted sequence numbers is that they can
start at zero, which reduces the size of ACK packets.

We may want to have a discussion about exposing a 1, 2 or 3 bit sequence
number in clear text, so intermediaries can observe it and deduce issues
like losses or reordering. But we should be deliberate about that, and
follow pretty much the same process as for reserving the spin bit.

-- Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Tue, 23 Jan 2018 11:50:33 -1000

> switch to for example var length encoding.

By the way, the have the same problem with the first octet. We may want
to encrypt the non invariant bits, in order to prevent ossification. But
we dedided to treat that separately from packet sequence number encryption.

-- Christian Huitema

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Wed, 24 Jan 2018 00:30:51 +0100

hi Christian, all,

> On 23 Jan 2018, at 22:42, Christian Huitema <[email-masked]> wrote:
> 
> was very complex.

Yeah, it seems so.

> But if we use the same encryption context across

Yep... most of my questions at this point are on the specifics on how this is supposed to work, so I'll wait for a PR before asking them.

> switch to for example var length encoding.

<aside about greasing>

Well.. we have an as-yet untested-at-scale hypothesis that greasing will decrease the likelihood of a certain, not-yet-very-rigorously defined model of ossification. Here, we seem to be assuming that path behavior will rapidly ossify around a set of functions applied to the vector of values of ranges of bits in the header, which I'm not sure  I buy.

Greasing makes a whole lot of sense in the abstract, and I'm a big fan of the "use it or lose it" insight. I'm not convinced that we can take experience with TLS and the QUIC blocking event (both of which react to static values in a session or a packet) and generalize it to "greasing prevents ossification" yet, though, and I think we need to evaluate the complexity cost against the prevalence of the specific middlebox actions we're trying to prevent.

</aside>

> start at zero, which reduces the size of ACK packets.

We already have that property with the secret-offset PR, but yeah, it's definitely worth trying to keep that property no matter what we do.

> follow pretty much the same process as for reserving the spin bit.

I will note that if we varint the packet number, or if encryption makes it fixed-length (either of which would appear to be true), we can claw back the type bits in the short header, and can stick the subsequence number there, i.e.:

+-+-+-+-+-+-+-+-+
|0|C|K|S|  SSN  |
+-+-+-+-+-+-+-+-+

unless we want to grab one of those bits for some other purpose. I suspect that four bits of subsequence are more useful than three bits, but that's just intuition; data about common loss and reordering patterns seen in large HTTP installations would be useful here.

I'll reserve comment on process for later, but I will note that encrypted packet numbers significantly change the current information content of the wire image, while encrypted packet numbers + subsequence numbers represent a less significant change.

Cheers,

Brian

---

From: <[email-masked]>
Date: Wed, 24 Jan 2018 15:32:51 +0100

On -10/01/-28163 20:59, Brian Trammell (IETF) wrote:
> I will note that if we varint the packet number, or if encryption makes it fixed-length (either of which would
> appear to be true), we can claw back the type bits in the short header, and can stick the subsequence number there,
> i.e.:
>
> +-+-+-+-+-+-+-+-+
> |0|C|K|S|  SSN  |
> +-+-+-+-+-+-+-+-+
>
> unless we want to grab one of those bits for some other purpose. I suspect that four bits of subsequence are more
 > useful than three bits, but that's just intuition; data about common loss and reordering patterns seen in large HTTP
 > installations would be useful here.

I confirm: four bits are more useful than three. But, as is obvious from tackling loss and reordering daily, it is
still insufficient: it sure allows detection of loss, in a yes-or-no fashion (with a probability ~ 15/16), but gives 
very few quantitative hints (the size or pattern of loss). For example, this makes it hard to distinguish large 
contiguous losses (due to a tail drop on a per-flow queue) from sparser ones (due to losses on a shared resource like a 
backbone router interface).

-Alex

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.