Subject: Simple transform for improving PN ossification prevention

From: Praveen Balasubramanian <[email-masked]>
Date: Mon, 9 Apr 2018 20:48:37 +0000

The current approach in the draft for preventing PN ossification is to use a random starting PN. Kazuho pointed out a problem with this approach where middleboxes could interpret the PN as a sequence number. And in an attempt to be "helpful", they could reorder the packets exacerbating the HoL blocking problem and may cause issues for unreliable semantics.

If the PN in the clear (the nonce value) didn't always monotonically increase then it will preclude such bad behavior by the middleboxes. Hence we need to find a simple transform that is not monotonically increasing and also not repeating.

Requirements for any PN transform in the single path case:

  1.  The actual PN must always increment by 1 and will be used for generating ACKs in ACK frames.
  2.  The transformed PN in the clear is a nonce and must not repeat over the connection lifetime.
  3.  Middleboxes must not be able to determine the actual PN. Only the QUIC receiver should be able to do so.

PNE is one possible transform that meets all these requirements but it is expensive CPU cost wise and has implications for hardware implementations.

Following is a proposal for an alternative simple transform with low CPU overhead which satisfies these three requirements. The goal is to produce a non-repeating shuffle of the original set of numbers. Since the PN space is very big and efficient shuffle algorithms have O(n) space requirement, we need to define a "reorder degree" or a "batch size" within which we will shuffle the packet numbers.

As an example consider that the starting random PN is 100. Per the current draft the actual PN increments as follows:
    100, 101, 102, 103, 104,    105, 106, 107, 108, 109, ... and so forth

Let's assume a "batch size" of 5. Then using one possible outcome of the shuffles we can generate the following as the cleartext nonces:
|  102, 104, 103, 101, 100, |  107, 105, 109, 108, 106 |   ,... and so forth
The bars | indicate batch boundaries.

Of course since we need the QUIC receiver to get the actual PN from the cleartext value, we need to communicate the offsets in the encrypted portion of the packet, which for this example would be:
|  +2,    +3,   +1,   -2,   -4,    |    -2,   +1,   -2,    0,     +3    |,  ....
Middleboxes will not be able to see the offset values in the clear. QUIC receiver will need to do a simple add of a signed number to get the original PN. This is very cheap operation CPU cost wise.

A QUIC sender implementation can pick any size for the reorder degree, the trade-off is the space complexity and packet space needed to communicate the offsets. A reorder degree within 128 numbers will need at most an extra byte in the encrypted header to communicate the signed offset values. The 128 batch size i.e. a 1 byte offset size should be more than enough entropy to discourage a middle box from "fixing reordering" and in practice we may need less.

One possible algorithm for the shuffle is the Fisher-Yates (Knuth) shuffle as documented here: https://en.wikipedia.org/wiki/Fisher-Yates_shuffle . Please see the "Modern method" section which is in-place. The random number generator doesn't have to be a secure variant.

One advantage of such a scheme is that packet loss can still be inferred by looking at each batch sized set of the nonce (packet numbers). For example if the batch size is 128, then missing numbers in this batch size (or a multiple) will show the extent of packet loss. The other advantage is that a QUIC diagnostic connection can trivially detect a bad middlebox that tries to reorder the nonce in sequence as it will be easily distinguishable from a random network reorder.

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Mon, 9 Apr 2018 17:20:06 -0400

I incidentally implemented Fisher-Yates a few days ago…

But if you permit a window, you can also encrypt packet numbers using an
internal precomputed AES driven PRNG stream - this is about 16x faster than
direct encryption because one block covers 4 packets, and encryption can be
done in a parallel pipeline with current AES-NI hardware. You need to map
the window in a hash table, and it must be small or cache effects makes it
too expensive.

However, big packet loss would make this scheme either ineffective, or
complicated with fallback search.

I assume your proposed shuffle is fully deterministic and precomputed.
Aside from the problems with a window size vs loss, this looks like a very
good way to correlate packets because they now exhibit a distinct pattern
for each connection. So I don’t see this as being worthwhile, if I
understand the scheme correctly.

The shuffle can also be seen as a clever way to create a perfect hash table
for the above mentioned PRNG scheme, but I don't think it would be
effective for large enough windows.

Furthermore, all of these schemes require extra memory per connection and
this can be expensive if there are 10K+ idle connections sitting.

/*
 * Given an uninitialized `index` of `n` uint64_t slots:
 * Place a unique value in the range 0 .. n - 1 inclusive in each slot
 * unbiased randomly (within the prng limits).
 *
 * Based on Fisher-Yates shuffle - inside out variant.
 */
static inline void rand64_init_shuffle_below(uint64_t *state, uint64_t
*index, uint64_t n)
{
    uint64_t i, x;

    for (i = 0; i < n; ++i) {
        x = rand64_below(state, i + 1); /* unsigned random value (0 .. i) */
        index[i] = index[x]; /* Uninitialized if i == x, which is ok. */
        index[x] = i;
    }
}

Mikkel

On 9 April 2018 at 22.48.48, Praveen Balasubramanian (
pravb=[email-masked]) wrote:

The current approach in the draft for preventing PN ossification is to use
a random starting PN. Kazuho pointed out a problem with this approach where
middleboxes could interpret the PN as a sequence number. And in an attempt
to be “helpful”, they could reorder the packets exacerbating the HoL
blocking problem and may cause issues for unreliable semantics.

If the PN *in the clear* (the nonce value) didn’t always monotonically
increase then it will preclude such bad behavior by the middleboxes. Hence
we need to find a simple transform that is not monotonically increasing and
also not repeating.

   1. The actual PN must always increment by 1 and will be used for
   generating ACKs in ACK frames.
   2. The transformed PN in the clear is a nonce and must not repeat over
   the connection lifetime.
   3. Middleboxes must not be able to determine the actual PN. Only the
   QUIC receiver should be able to do so.

PNE is one possible transform that meets all these requirements but it is
expensive CPU cost wise and has implications for hardware implementations.

Following is a proposal for an alternative simple transform with low CPU
overhead which satisfies these three requirements. The goal is to produce a
non-repeating shuffle of the original set of numbers. Since the PN space is
very big and efficient shuffle algorithms have O(n) space requirement, we
need to define a “reorder degree” or a “batch size” within which we will
shuffle the packet numbers.

As an example consider that the starting random PN is 100. Per the current
draft the actual PN increments as follows:

    100, 101, 102, 103, 104,    105, 106, 107, 108, 109, … and so forth

Let’s assume a “batch size” of 5. Then using one possible outcome of the
shuffles we can generate the following as the cleartext nonces:

|  102, 104, 103, 101, 100, |  107, 105, 109, 108, 106 |   ,… and so forth

Of course since we need the QUIC receiver to get the actual PN from the
cleartext value, we need to communicate the offsets in the encrypted
portion of the packet, which for this example would be:

|  +2,    +3,   +1,   -2,   -4,    |    -2,   +1,   -2,    0,     +3    |,
 ….

Middleboxes will not be able to see the offset values in the clear. QUIC
receiver will need to do a simple add of a signed number to get the
original PN. This is very cheap operation CPU cost wise.

A QUIC sender implementation can pick any size for the reorder degree, the
trade-off is the space complexity and packet space needed to communicate
the offsets. A reorder degree within 128 numbers will need at most an extra
byte in the encrypted header to communicate the signed offset values. The
128 batch size i.e. a 1 byte offset size should be more than enough entropy
to discourage a middle box from “fixing reordering” and in practice we may
need less.

One possible algorithm for the shuffle is the Fisher–Yates (Knuth) shuffle
as documented here: https://en.wikipedia.org/wiki/Fisher–Yates_shuffle .
Please see the “Modern method” section which is in-place. The random number
generator doesn’t have to be a secure variant.

One advantage of such a scheme is that packet loss can still be inferred by
looking at each batch sized set of the nonce (packet numbers). For example
if the batch size is 128, then missing numbers in this batch size (or a
multiple) will show the extent of packet loss. The other advantage is that
a QUIC diagnostic connection can trivially detect a bad middlebox that
tries to reorder the nonce in sequence as it will be easily distinguishable
from a random network reorder.

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Mon, 9 Apr 2018 17:20:06 -0400

/*

Mikkel

---

From: Nick Banks <[email-masked]>
Date: Mon, 9 Apr 2018 21:33:04 +0000

The goal here would essentially just to shuffle the bits in the bottom byte, just to make everything look reordered to the middlebox. You don’t really have to precompute anything, and it should be independent of BDP or loss.

Here is a slight variation on Praveen’s suggestion (assumes using full 128 packet batch size):

  *   Preallocate a buffer of 128 bytes and prepopulate it with the values of 0 to 127.
  *   For each packet sent, randomly grab an item (i.e. the offset) from what’s left in the buffer, and remove it (swap with last value, and decrement length).
  *   Replace the bottom byte of the real packet number with the offset and put that new packet number in the clear text.
  *   Put the real bottom byte of the real packet number in the encrypted portion.
  *   Encrypt with the new cleartext packet number and send.
  *   Once the preallocated buffer is empty, just set the length back to 128 and continue on.

The sender decrypts using the cleartext packet number. Then replaces the bottom byte of the packet number with the offset from the encrypted payload to get the true packet number.

- Nick

From: QUIC <[email-masked]> On Behalf Of Mikkel Fahnøe Jørgensen
Sent: Monday, April 9, 2018 2:20 PM
To: Praveen Balasubramanian <pravb=[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: Re: Simple transform for improving PN ossification prevention

But if you permit a window, you can also encrypt packet numbers using an internal precomputed AES driven PRNG stream - this is about 16x faster than direct encryption because one block covers 4 packets, and encryption can be done in a parallel pipeline with current AES-NI hardware. You need to map the window in a hash table, and it must be small or cache effects makes it too expensive.

However, big packet loss would make this scheme either ineffective, or complicated with fallback search.

I assume your proposed shuffle is fully deterministic and precomputed. Aside from the problems with a window size vs loss, this looks like a very good way to correlate packets because they now exhibit a distinct pattern for each connection. So I don’t see this as being worthwhile, if I understand the scheme correctly.

The shuffle can also be seen as a clever way to create a perfect hash table for the above mentioned PRNG scheme, but I don't think it would be effective for large enough windows.

Furthermore, all of these schemes require extra memory per connection and this can be expensive if there are 10K+ idle connections sitting.

/*
 * Given an uninitialized `index` of `n` uint64_t slots:
 * Place a unique value in the range 0 .. n - 1 inclusive in each slot
 * unbiased randomly (within the prng limits).
 *
 * Based on Fisher-Yates shuffle - inside out variant..
 */
static inline void rand64_init_shuffle_below(uint64_t *state, uint64_t *index, uint64_t n)
{
    uint64_t i, x;

Mikkel

On 9 April 2018 at 22.48.48, Praveen Balasubramanian (pravb=[email-masked]<mailto:pravb=[email-masked]>) wrote:
The current approach in the draft for preventing PN ossification is to use a random starting PN. Kazuho pointed out a problem with this approach where middleboxes could interpret the PN as a sequence number. And in an attempt to be “helpful”, they could reorder the packets exacerbating the HoL blocking problem and may cause issues for unreliable semantics.

If the PN in the clear (the nonce value) didn’t always monotonically increase then it will preclude such bad behavior by the middleboxes. Hence we need to find a simple transform that is not monotonically increasing and also not repeating.

Following is a proposal for an alternative simple transform with low CPU overhead which satisfies these three requirements. The goal is to produce a non-repeating shuffle of the original set of numbers. Since the PN space is very big and efficient shuffle algorithms have O(n) space requirement, we need to define a “reorder degree” or a “batch size” within which we will shuffle the packet numbers.

Let’s assume a “batch size” of 5. Then using one possible outcome of the shuffles we can generate the following as the cleartext nonces:
|  102, 104, 103, 101, 100, |  107, 105, 109, 108, 106 |   ,… and so forth
The bars | indicate batch boundaries.

Of course since we need the QUIC receiver to get the actual PN from the cleartext value, we need to communicate the offsets in the encrypted portion of the packet, which for this example would be:
|  +2,    +3,   +1,   -2,   -4,    |    -2,   +1,   -2,    0,     +3    |,  ….
Middleboxes will not be able to see the offset values in the clear. QUIC receiver will need to do a simple add of a signed number to get the original PN. This is very cheap operation CPU cost wise.

A QUIC sender implementation can pick any size for the reorder degree, the trade-off is the space complexity and packet space needed to communicate the offsets. A reorder degree within 128 numbers will need at most an extra byte in the encrypted header to communicate the signed offset values. The 128 batch size i.e. a 1 byte offset size should be more than enough entropy to discourage a middle box from “fixing reordering” and in practice we may need less.

One possible algorithm for the shuffle is the Fisher–Yates (Knuth) shuffle as documented here: https://en.wikipedia.org/wiki/Fisher–Yates_shuffle<https://na01.safelinks.protection.outlook.com/?url=https:%2F%2Fen.wikipedia.org%2Fwiki%2FFisher%E2%80%93Yates_shuffle&data=02%7C01%7Cnibanks%40microsoft.com%7Ccb1d2deab551419fb32208d59e5fb069%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636589056193862868&sdata=IQhNPr1Q6Sg%2B54oAClbyGhHd6q7rlwrP9euH6QkY6EU%3D&reserved=0> . Please see the “Modern method” section which is in-place. The random number generator doesn’t have to be a secure variant.

---

From: Nick Banks <[email-masked]>
Date: Mon, 9 Apr 2018 21:33:04 +0000

- Nick

/*

Mikkel

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Mon, 9 Apr 2018 17:52:23 -0400

OK, so the high bits are kept - this solves the loss problem.
And the sender does not have to decode the shuffle because the packet
number is the packet number - which makes the shuffle order non-recurring
in the batch, but it also makes loss detection very difficult to do with
any degree of precision.
Privacy is also not a goal here because the high bits are an immediate
giveaway if the window is small. Just the average distance between two 0
bytes on the low packet number would make a strong correlation.

So I’m not really sure why - if it is to prevent middle boxes from adding
reordering latency by being unorganized, one has to hope that a middlebox
does not try to reorder anyway, but ok, I see.

I’m not convinced. But the scheme has another brilliant property: it solves
the optimistic ACK attack problem with needing to introduce any artificial
gaps. This could be useful even if packet numbers were fully encrypted
because the attacker is then the receiver - were it not for the problem
with loss detection and early retransmission.

On 9 April 2018 at 23.33.05, Nick Banks ([email-masked]) wrote:

The goal here would essentially just to shuffle the bits in the bottom
byte, just to make everything look reordered to the middlebox. You don’t
really have to precompute anything, and it should be independent of BDP or
loss.

Here is a slight variation on Praveen’s suggestion (assumes using full 128
packet batch size):

   - Preallocate a buffer of 128 bytes and prepopulate it with the values
   of 0 to 127.
   - For each packet sent, randomly grab an item (i.e. the offset) from
   what’s left in the buffer, and remove it (swap with last value, and
   decrement length).
   - Replace the bottom byte of the real packet number with the offset and
   put that new packet number in the clear text.
   - Put the real bottom byte of the real packet number in the encrypted
   portion.
   - Encrypt with the new cleartext packet number and send.
   - Once the preallocated buffer is empty, just set the length back to 128
   and continue on.

The sender decrypts using the cleartext packet number. Then replaces the
bottom byte of the packet number with the offset from the encrypted payload
to get the true packet number.

- Nick

*From:* QUIC <[email-masked]> *On Behalf Of * Mikkel Fahnøe Jørgensen
*Sent:* Monday, April 9, 2018 2:20 PM
*To:* Praveen Balasubramanian <pravb=[email-masked]>; IETF
QUIC WG <[email-masked]>
*Subject:* Re: Simple transform for improving PN ossification prevention

/*

 *

 */

{

    uint64_t i, x;

        index[x] = i;

    }

}

Mikkel

One possible algorithm for the shuffle is the Fisher–Yates (Knuth) shuffle
as documented here: https://en.wikipedia.org/wiki/Fisher–Yates_shuffle
<https://na01.safelinks.protection.outlook.com/?url=https:%2F%2Fen.wikipedia.org%2Fwiki%2FFisher%E2%80%93Yates_shuffle&data=02%7C01%7Cnibanks%40microsoft.com%7Ccb1d2deab551419fb32208d59e5fb069%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636589056193862868&sdata=IQhNPr1Q6Sg%2B54oAClbyGhHd6q7rlwrP9euH6QkY6EU%3D&reserved=0>
. Please see the “Modern method” section which is in-place. The random
number generator doesn’t have to be a secure variant.

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Mon, 9 Apr 2018 17:52:23 -0400

- Nick

/*

 *

 */

{

    uint64_t i, x;

        index[x] = i;

    }

}

Mikkel

.. Please see the “Modern method” section which is in-place. The random

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Mon, 9 Apr 2018 17:57:02 -0400

Sorry, the loss is handled by duplication of the packet number in the
encrypted portion, but this then prevents it from protecting against
optimistic ACK attacks.

On 9 April 2018 at 23.52.23, Mikkel Fahnøe Jørgensen ([email-masked])
wrote:

- Nick

/*

 *

 */

{

    uint64_t i, x;

        index[x] = i;

    }

}

Mikkel

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Mon, 9 Apr 2018 17:57:02 -0400

- Nick

/*

 *

 */

{

    uint64_t i, x;

        index[x] = i;

    }

}

Mikkel

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Apr 2018 10:31:33 +1000

Hi Praveen,

Thanks for sharing your thoughts on this.

Let's look at the requirements a little closer first, because I think
that this isn't quite right.

On Tue, Apr 10, 2018 at 6:48 AM, Praveen Balasubramanian
<pravb=[email-masked]> wrote:
> The actual PN must always increment by 1 and will be used for generating
> ACKs in ACK frames.

This is good.

> The transformed PN in the clear is a nonce and must not repeat over the
> connection lifetime.

I don't think that this is correct, or at least it could be turned
into a requirement and a separate insight about that observation.
Namely that the PN is used as a nonce, but we don't need to use nonces
in the order they are presented.

What is incorrect here is that we use the actual PN as a nonce.  This
confusion is understandable because - at the moment - we shift the
actual PN by a random offset.  But that's a mistake and we should
rectify that anyway as #1079 does.  Even if we don't do #1079, any
design we have can and should remove that initial randomization and
use a random offset transformation instead; the same for packet number
gaps: we can use a different random offset in the transformation.

But I see where you are going with this.  You want to use a packet
number that is near the real packet number, ensure that each value is
only used once, and also include the real packet number under
encryption.  Given that, if it weren't for the way that loss detection
reacts to reordering, you could almost just send packets with out of
order packet numbers.

The effect of this is that the degree to which you do this
"reordering" will affect the performance of the packet number
reconstruction in the face of actual reordering.  That puts a hard
upper limit on the amount of reordering you do.   It will also cost
some number of bytes to reconstruct the real packet number.

> Middleboxes must not be able to determine the actual PN. Only the QUIC
> receiver should be able to do so.

This sounds like a good goal, but I think that your design misses it.
The point with the #1079 design is that it is semantically secure: you
need the keys to get the real packet number.

In your design, a middlebox can reconstruct packet numbers with high
fidelity based on arrival times and knowledge of the non-secret
parameter (the 5 you used in your example).  Only reordering within
that set (e.g., between packet 101 and 102 in your example) will be
undetectable, but reordering across a boundary (e.g., between packet
104 and 105) will be easily detectable.  Finally, if the PRNG used to
seed Fisher-Yates isn't a CSPRNG, then its state can be reconstructed
eventually and then the reordering problem goes away.

So all that this effectively does is confound the process by which
things like the spin bit are managed.  It doesn't provide any real
barrier.

But maybe that is the real goal, to make it harder to do this, on the
assumption that anyone willing to do that won't also ossify the
protocol in the process.  I don't see that happening, but that's
clearly a point on which different people reach different conclusions.

FWIW, Fisher-Yates is pretty inefficient as a PRP.  I'm surprised that
you are suggesting it.  How are you seeding the PRNG?  Is it a CSPRNG?
 Have you tested the overall performance?

A different cheap PRP would be XOR-shift (PN>>a|PN>>b|PN>>c), or (PN +
a) * b.  They are each trivially reversed though.  While that violates
your stipulated requirement, it doesn't violate the implied one.  If
the requirement is that it be *difficult* to reconstruct the actual
packet number based on the sequence of transformed packet numbers,
then maybe those are better.  Based on those you wouldn't need to also
include the real packet number under encryption, which saves that many
octets.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Apr 2018 10:31:33 +1000

Hi Praveen,

This is good.

---

From: Praveen Balasubramanian <[email-masked]>
Date: Tue, 10 Apr 2018 00:49:44 +0000

>> You want to use a packet number that is near the real packet number, ensure that each value is only used once, and also include the real packet number under encryption
Not the entire packet number, just enough information to reconstruct the real packet number. In this scheme it is just an extra byte in the encrypted portion of the header. IF the batch size is smaller we can do fewer bits per packet. 

>> to which you do this "reordering" will affect the performance of the packet number reconstruction in the face of actual reordering
Each packet is self contained and the real PN can be reconstructed just using the offset stored in the encrypted header. I don’t see any issues with additional network induced reordering. There is no dependency between packets with this scheme.

>> middlebox can reconstruct packet numbers
The number 5 was for illustrative purposes. In practice the actual value would likely need to be between 32 to 128. The middlebox has no information about the offsets and I don’t see what purpose is served by it trying to guess any order. By reordering all numbers we leave little room for a middlebox to make a mistake around trying to reorder packets using the nonce field. Remember that this scheme is for single path and is not trying to solve linkability. It is just trying to prevent ossification by doing better greasing. 

>> confound the process by which things like the spin bit are managed
I concede that I haven’t thought of the implications to spin bit, but I suspect that as long as batches are within the RTT there is no actual issue since RTT detection is not dependent on the PN. Why would it matter if the PN is transformed using this scheme or with encryption? Remember we are not actually reordering packets, just reordering the clear text nonce value.

>> Re. Fisher-Yates perf
I am not suggesting this as the only possible algorithm for generating non-repeating random numbers. I certainly don’t think we need to make the transform secure. I don’t think its an issue if the middlebox goes out of its way to do offline analysis to figure out the right PN. We are not trying to solve unlinkability with this scheme. It is just better ossification prevention for connections that are on a single path.

-----Original Message-----
From: QUIC [mailto:[email-masked]] On Behalf Of Martin Thomson
Sent: Monday, April 9, 2018 5:32 PM
To: Praveen Balasubramanian <pravb=[email-masked]>
Cc: IETF QUIC WG <[email-masked]>
Subject: Re: Simple transform for improving PN ossification prevention

Hi Praveen,

Let's look at the requirements a little closer first, because I think that this isn't quite right.

On Tue, Apr 10, 2018 at 6:48 AM, Praveen Balasubramanian <pravb=[email-masked]> wrote:
> The actual PN must always increment by 1 and will be used for 

This is good.

> The transformed PN in the clear is a nonce and must not repeat over 
> the connection lifetime.

I don't think that this is correct, or at least it could be turned into a requirement and a separate insight about that observation.
Namely that the PN is used as a nonce, but we don't need to use nonces in the order they are presented.

What is incorrect here is that we use the actual PN as a nonce.  This confusion is understandable because - at the moment - we shift the actual PN by a random offset.  But that's a mistake and we should rectify that anyway as #1079 does.  Even if we don't do #1079, any design we have can and should remove that initial randomization and use a random offset transformation instead; the same for packet number
gaps: we can use a different random offset in the transformation.

But I see where you are going with this.  You want to use a packet number that is near the real packet number, ensure that each value is only used once, and also include the real packet number under encryption.  Given that, if it weren't for the way that loss detection reacts to reordering, you could almost just send packets with out of order packet numbers.

The effect of this is that the degree to which you do this "reordering" will affect the performance of the packet number reconstruction in the face of actual reordering.  That puts a hard
upper limit on the amount of reordering you do.   It will also cost
some number of bytes to reconstruct the real packet number.

This sounds like a good goal, but I think that your design misses it.
The point with the #1079 design is that it is semantically secure: you need the keys to get the real packet number.

In your design, a middlebox can reconstruct packet numbers with high fidelity based on arrival times and knowledge of the non-secret parameter (the 5 you used in your example).  Only reordering within that set (e.g., between packet 101 and 102 in your example) will be undetectable, but reordering across a boundary (e.g., between packet
104 and 105) will be easily detectable.  Finally, if the PRNG used to seed Fisher-Yates isn't a CSPRNG, then its state can be reconstructed eventually and then the reordering problem goes away.

So all that this effectively does is confound the process by which things like the spin bit are managed.  It doesn't provide any real barrier.

But maybe that is the real goal, to make it harder to do this, on the assumption that anyone willing to do that won't also ossify the protocol in the process.  I don't see that happening, but that's clearly a point on which different people reach different conclusions.

FWIW, Fisher-Yates is pretty inefficient as a PRP.  I'm surprised that you are suggesting it.  How are you seeding the PRNG?  Is it a CSPRNG?
 Have you tested the overall performance?

A different cheap PRP would be XOR-shift (PN>>a|PN>>b|PN>>c), or (PN +
a) * b.  They are each trivially reversed though.  While that violates your stipulated requirement, it doesn't violate the implied one.  If the requirement is that it be *difficult* to reconstruct the actual packet number based on the sequence of transformed packet numbers, then maybe those are better.  Based on those you wouldn't need to also include the real packet number under encryption, which saves that many octets.

---

From: Praveen Balasubramanian <[email-masked]>
Date: Tue, 10 Apr 2018 00:49:44 +0000

-----Original Message-----
From: QUIC [mailto:[email-masked]] On Behalf Of Martin Thomson
Sent: Monday, April 9, 2018 5:32 PM
To: Praveen Balasubramanian <pravb=[email-masked]>
Cc: IETF QUIC WG <[email-masked]>
Subject: Re: Simple transform for improving PN ossification prevention

Hi Praveen,

This is good.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Apr 2018 10:57:58 +1000

> Not the entire packet number, just enough information to reconstruct the real packet number. In this scheme it is just an extra byte in the encrypted portion of the header. IF the batch size is sma…

If I understand your scheme, then you reconstruct the nonce in the
same way that you reconstruct the packet number.  Is that a
misunderstanding?  Or are you suggesting that there is an explicit
nonce in the packet?

> Each packet is self contained and the real PN can be reconstructed just using the offset stored in the encrypted header. I don’t see any issues with additional network induced reordering. There is…

The current design places requirements on the size of the truncated
packet number that is based on the exposure to reordering.  Your
design effectively induces reordering into this process, so the number
of bytes you spend on the "packet number" (really a nonce in your
design) encoding has to increase to compensate.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Apr 2018 10:57:58 +1000

---

From: Praveen Balasubramanian <[email-masked]>
Date: Tue, 10 Apr 2018 01:07:18 +0000

Since the text is verbose maybe this pseudo code explains it in an easy way:

1. Set batch_size = 128. Allocate an array A of 128 packet numbers per connection. Set i = 0. 

2. For generating each packet
              If i < batch_size 
              {
		a. use Fisher-Yates (or equivalent) on the array to generate the next unique random number R between "real packet number" and "real packet number" + 128
		b. i++
		c. set R as the nonce (in clear packet number) after encoding
		d. set ("real packet number" - R), i.e. the subtraction as a signed offset value O in encrypted portion of the header. O is by definition <= 128 and as a signed 	number needs at most a byte to represent in the packet.
		e. "real packet number"++
		f. Do rest of steps of generating a packet then Done
               }
	else 
               {
		a. clear the array, reset i = 0
                             b. goto 2.
               }

I am not really sure why the transformed PN which always is within 128 (or batch_size) numbers of the original PN will need more space to encode. 

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Monday, April 9, 2018 5:58 PM
To: Praveen Balasubramanian <[email-masked]>
Cc: Praveen Balasubramanian <pravb=[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: Re: Simple transform for improving PN ossification prevention

On Tue, Apr 10, 2018 at 10:49 AM, Praveen Balasubramanian <[email-masked]> wrote:
>>> You want to use a packet number that is near the real packet number, 
>>> ensure that each value is only used once, and also include the real 
>>> packet number under encryption

If I understand your scheme, then you reconstruct the nonce in the same way that you reconstruct the packet number.  Is that a misunderstanding?  Or are you suggesting that there is an explicit nonce in the packet?

>>> to which you do this "reordering" will affect the performance of the 
>>> packet number reconstruction in the face of actual reordering

The current design places requirements on the size of the truncated packet number that is based on the exposure to reordering.  Your design effectively induces reordering into this process, so the number of bytes you spend on the "packet number" (really a nonce in your
design) encoding has to increase to compensate.

---

From: Praveen Balasubramanian <[email-masked]>
Date: Tue, 10 Apr 2018 01:07:18 +0000

---

From: Praveen Balasubramanian <[email-masked]>
Date: Tue, 10 Apr 2018 01:11:57 +0000

Including receiver pseudo code for completeness:

On receiving packet:
1. Decrypt packet using decoded nonce R. The value O will now be available. 
2. Calculate "real packet number" = R + O.

---

From: Praveen Balasubramanian <[email-masked]>
Date: Tue, 10 Apr 2018 01:11:57 +0000

On receiving packet:

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Apr 2018 11:22:07 +1000

Do you truncate the randomized value?  Do you reconstruct using the
process for reconstructing a packet number in the current QUIC draft?

If the answer is yes to both, then you need to add batch_size to the
number of outstanding packets when determining the length of the
truncated packet number.  That's all.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Apr 2018 11:22:07 +1000

---

From: Praveen Balasubramanian <[email-masked]>
Date: Tue, 10 Apr 2018 01:27:45 +0000

Yes to both. Yeah thanks I agree that addition will be required since the nonce value ("real packet number" + batch_size) may very well arrive first in a given  batch. 

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Monday, April 9, 2018 6:22 PM
To: Praveen Balasubramanian <[email-masked]>
Cc: Praveen Balasubramanian <pravb=[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: Re: Simple transform for improving PN ossification prevention

Do you truncate the randomized value?  Do you reconstruct using the process for reconstructing a packet number in the current QUIC draft?

If the answer is yes to both, then you need to add batch_size to the number of outstanding packets when determining the length of the truncated packet number.  That's all.

On Tue, Apr 10, 2018 at 11:07 AM, Praveen Balasubramanian <[email-masked]> wrote:
>>>> You want to use a packet number that is near the real packet 
>>>> number, ensure that each value is only used once, and also include 
>>>> the real packet number under encryption
>>>> to which you do this "reordering" will affect the performance of 
>>>> the packet number reconstruction in the face of actual reordering

---

From: Praveen Balasubramanian <[email-masked]>
Date: Tue, 10 Apr 2018 01:27:45 +0000

---

From: Praveen Balasubramanian <[email-masked]>
Date: Tue, 10 Apr 2018 01:36:56 +0000

>> but it also makes loss detection very difficult to do with any degree of precision
Loss detection is actually straightforward as long as the middlebox knows the batch size. It will need to look for missing packet numbers within a batch. Reorder detection is however extremely difficult since the scheme itself does reordering of the nonce.

>> you can also encrypt packet numbers using an internal precomputed AES driven PRNG stre
An implementation could but its not a must. The random generation for shuffling doesn’t need to be cryptographically secure, only guarantee uniqueness.

>> I assume your proposed shuffle is fully deterministic and precomputed
Fisher-Yates requires O(n) space corresponding to the batch size but there is no need to precompute. You can generate the next random number within the batch as you go generating packets or you can also do it up front per batch. Determinism depends on PRNG and seed.

>> all of these schemes require extra memory per connection
Agreed there is memory overhead but its constant size. With a batch size of 128 you will need 128*sizeof(PN) bytes. In practice if we decide a much smaller batch size is sufficient like 32, then the space requirement becomes much less and will also require fewer bits for the offset values to be communicated per packet.

Thanks

From: Mikkel Fahnøe Jørgensen [mailto:[email-masked]]
Sent: Monday, April 9, 2018 2:57 PM
To: Nick Banks <[email-masked]>; Praveen Balasubramanian <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: RE: Simple transform for improving PN ossification prevention

Sorry, the loss is handled by duplication of the packet number in the encrypted portion, but this then prevents it from protecting against optimistic ACK attacks.

On 9 April 2018 at 23.52.23, Mikkel Fahnøe Jørgensen ([email-masked]<mailto:[email-masked]>) wrote:
OK, so the high bits are kept - this solves the loss problem.
And the sender does not have to decode the shuffle because the packet number is the packet number - which makes the shuffle order non-recurring in the batch, but it also makes loss detection very difficult to do with any degree of precision.
Privacy is also not a goal here because the high bits are an immediate giveaway if the window is small. Just the average distance between two 0 bytes on the low packet number would make a strong correlation.

So I’m not really sure why - if it is to prevent middle boxes from adding reordering latency by being unorganized, one has to hope that a middlebox does not try to reorder anyway, but ok, I see.

I’m not convinced. But the scheme has another brilliant property: it solves the optimistic ACK attack problem with needing to introduce any artificial gaps. This could be useful even if packet numbers were fully encrypted because the attacker is then the receiver - were it not for the problem with loss detection and early retransmission.

On 9 April 2018 at 23.33.05, Nick Banks ([email-masked]<mailto:[email-masked]>) wrote:
The goal here would essentially just to shuffle the bits in the bottom byte, just to make everything look reordered to the middlebox. You don’t really have to precompute anything, and it should be independent of BDP or loss.

  *   Put the real bottom byte of the real packet number in the encrypted portion..

- Nick

From: QUIC <[email-masked]<mailto:[email-masked]>> On Behalf Of Mikkel Fahnøe Jørgensen
Sent: Monday, April 9, 2018 2:20 PM
To: Praveen Balasubramanian <pravb=[email-masked]<mailto:[email-masked]>>; IETF QUIC WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: Simple transform for improving PN ossification prevention

/*

Mikkel

---

From: Christian Huitema <[email-masked]>
Date: Tue, 10 Apr 2018 00:17:39 -0700

I am not sure that I understand well the limitations of the shuffle
scheme. I am concerned that it smells like encryption, but can be
trivially broken, and if it is broken we will get ossification.

In my spare time, I have been thinking of similar schemes, but they
start with a big assumption: assume that we can encrypt short numbers.
That is, assume for example that we have a reasonable 32 bit encryption
code. I understand that the current such codes are a bit limited, and
that IPCrypt in particular may not be safe, but bear with me please
because of two reasons:

1) With 32 bit numbers, the number of permutations of a set of 2^32
values is much larger than 2**256. It is thus plausible that we can
design a symmetric encryption scheme keyed with a 256 bit or 128 bit key.

2) Designing encryption schemes is hard, but I assume that
cryptographers can come with plausible schemes if we ask them,
especially if we do not insist too much on performance. For example,
given a 32 bit permutation, repeat in a loop "XOR with 32-bit word index
I mod N of Key, then apply permutation" enough times and you get a
pretty reasonable scheme. (IPCrypt had just 3 passes of the loop and a
final XOR; that seemed a bit optimistic; more passes would be harder to
crack; my vote would be for at least 8; it would be more than twice
slower but who really cares?)

The big issue is that the same sequence of PN would repeat after 2*32
packets, but there is an obvious fix to that: rekey after at most 2**31
packets. Bingo, we get people to actually implement key rotation...

The other downside is that packets would be encoded on 4 bytes all the
time. But that might be an OK price for those who really want hardware
acceleration.

-- Christian Huitema

---

From: Victor Vasiliev <[email-masked]>
Date: Tue, 10 Apr 2018 08:03:31 +0000

On Mon, Apr 9, 2018, 13:48 Praveen Balasubramanian <pravb=
[email-masked]> wrote:

> Well, this sounds like you're requiring a block cipher.

---

From: Victor Vasiliev <[email-masked]>
Date: Tue, 10 Apr 2018 08:03:31 +0000

---

From: Praveen Balasubramanian <[email-masked]>
Date: Tue, 10 Apr 2018 16:37:43 +0000

With the shuffle scheme, if a middlebox wants to go out of its way to do analysis to break a PRNG and find the packet number it can. The scheme is not even requiring a secure random number. The goal is not to provide any security around PN, just prevent ossification by dumb middleboxes that assume the nonce is a sequence number and try to reorder. I don’t see any harm if costly analysis can allow on path determination of packet numbers. I stated this before but this is just improving ossification prevention, not providing any security or unlinkability etc.

From: QUIC [mailto:[email-masked]] On Behalf Of Victor Vasiliev
Sent: Tuesday, April 10, 2018 1:04 AM
To: Praveen Balasubramanian <pravb=[email-masked]>
Cc: IETF QUIC WG <[email-masked]>
Subject: Re: Simple transform for improving PN ossification prevention

On Mon, Apr 9, 2018, 13:48 Praveen Balasubramanian <pravb=[email-masked]<mailto:[email-masked]>> wrote:
Requirements for any PN transform in the single path case:

---

From: Praveen Balasubramanian <[email-masked]>
Date: Tue, 10 Apr 2018 16:37:43 +0000

---

From: Ryan Hamilton <[email-masked]>
Date: Tue, 10 Apr 2018 13:19:31 -0700

On Tue, Apr 10, 2018 at 9:37 AM, Praveen Balasubramanian <
pravb=[email-masked]> wrote:

> With the shuffle scheme, if a middlebox wants to go out of its way to do
> analysis to break a PRNG and find the packet number it can. The scheme is
> not even requiring a secure random number. The goal is not to provide any
> security around PN, just prevent ossification by dumb middleboxes that
> assume the nonce is a sequence number and try to reorder. I don’t see any
> harm if costly analysis can allow on path determination of packet numbers..
>

Are you concerned about "helpful" middlebox which are willing to expend the
resources to do costly analysis in order to "repair" packet reorder (and
consequently introduce HOL blocking)

---

From: Ryan Hamilton <[email-masked]>
Date: Tue, 10 Apr 2018 13:19:31 -0700

On Tue, Apr 10, 2018 at 9:37 AM, Praveen Balasubramanian <
pravb=[email-masked]> wrote:

> harm if costly analysis can allow on path determination of packet numbers.
>

---

From: Ryan Hamilton <[email-masked]>
Date: Tue, 10 Apr 2018 13:19:31 -0700

---

From: Praveen Balasubramanian <[email-masked]>
Date: Tue, 10 Apr 2018 22:36:25 +0000

No I am not concerned. Also it is speculation that a middlebox can actually do this with the shuffle scheme where each implementation is free to pick the PRNG, the shuffle algorithm, and change it over time. Implementations can also seed the PRNG for each connection.

Middleboxes need to operate at line rate and cannot do any expensive operations and any guessed reordering will make things even worse performance wise. An obnoxious middlebox can always drop all QUIC traffic and force fallback to TCP. One can construct bad middlebox behavior on a wide spectrum. One can also design ossification prevention solutions that make endpoints do either very little work or a lot of work. There are trade-offs.

The goal here was to explore a low CPU cost transform that can do better greasing of the field with no monotonic increase, specifically to prevent dumb middleboxes from treating the nonce as a sequence number.

From: QUIC [mailto:[email-masked]] On Behalf Of Ryan Hamilton
Sent: Tuesday, April 10, 2018 1:20 PM
To: Praveen Balasubramanian <[email-masked]>
Cc: Victor Vasiliev <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: Re: Simple transform for improving PN ossification prevention

On Tue, Apr 10, 2018 at 9:37 AM, Praveen Balasubramanian <pravb=[email-masked]<mailto:pravb=[email-masked]>> wrote:
With the shuffle scheme, if a middlebox wants to go out of its way to do analysis to break a PRNG and find the packet number it can. The scheme is not even requiring a secure random number. The goal is not to provide any security around PN, just prevent ossification by dumb middleboxes that assume the nonce is a sequence number and try to reorder. I don’t see any harm if costly analysis can allow on path determination of packet numbers.

Are you concerned about "helpful" middlebox which are willing to expend the resources to do costly analysis in order to "repair" packet reorder (and consequently introduce HOL blocking)

---

From: Praveen Balasubramanian <[email-masked]>
Date: Tue, 10 Apr 2018 22:36:25 +0000

---

From: Mike Bishop <[email-masked]>
Date: Wed, 11 Apr 2018 00:02:41 +0000

While “helpful” middleboxes are one thing we want to avoid, and a shuffle might reduce their incentives, we also want to preserve our options for a future version in which QUIC is multipath.  That means different packets will take different paths.

To me, there are two options that would get us in that space:

  *   Per-path packet number spaces plus a shuffle-style operation for the numbers on each path
  *   Encryption of the packet numbers

I’m concerned that the first option might still leave enough of a hole for ossification to develop.  Your own comment on this thread that “loss detection is actually straightforward” by looking for missing packet numbers is an excellent example of the ossifying assumptions we’re trying to make it difficult/impossible for middleboxes to grow.  That’s true only if there’s a single path or if every path has its own packet number space.

From: QUIC [mailto:[email-masked]] On Behalf Of Praveen Balasubramanian
Sent: Tuesday, April 10, 2018 3:36 PM
To: Ryan Hamilton <[email-masked]>
Cc: Victor Vasiliev <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: RE: Simple transform for improving PN ossification prevention

From: QUIC [mailto:[email-masked]] On Behalf Of Ryan Hamilton
Sent: Tuesday, April 10, 2018 1:20 PM
To: Praveen Balasubramanian <[email-masked]<mailto:[email-masked]>>
Cc: Victor Vasiliev <[email-masked]<mailto:[email-masked]>>; IETF QUIC WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: Simple transform for improving PN ossification prevention

---

From: Mike Bishop <[email-masked]>
Date: Wed, 11 Apr 2018 00:02:41 +0000

---

From: Praveen Balasubramanian <[email-masked]>
Date: Wed, 11 Apr 2018 01:03:37 +0000

Yes the shuffle scheme doesn’t attempt to prevent loss detection. But loss detection is a passive operation and is very different from reordering. It does not hurt end to end behavior or performance. Since PN is not part of invariants, if the PN field size changes, or the way its encoded changes, then the middlebox logic for loss detection will break and I don’t see that as a problem.

That said In the cloud we measure TCP loss and RTT variance on behalf of IaaS VM’s as indicators of performance issues. It would be nice to be able to do that with QUIC. IMO there are three things that are useful to middleboxes as passive information – RTT, loss, and connection closure signal -- and I don’t have a problem with exposing those, especially if it means more scenarios work better and less networks block QUIC.

I completely agree with your summary. Expanding on it somewhat further:

1. For connections guaranteed to be on a single path, there are no linkability concerns. In this case it would be nice to solve the ossification problem. The shuffle scheme aims to prevent “helpful” reordering but doesn’t promise much else. It also does greasing of the field. PNE will achieve even better greasing but it has much higher CPU costs and hardware implications. There is likley a spectrum of schemes (including cheaper encryption) here with different trade-offs. I am not married to any scheme but I will strongly prefer schemes that are cheap CPU cost wise because we are not adding any user value, and only preventing ossification (i.e. this is an internal protocol evolution problem which workload owners won’t care much about).

2. For connections on multiple paths (gratuitous migration, or true multi path), unlinkability has been proposed as a goal but not everyone seems to agree if its needed or achievable. If there is consensus that we need unlinkability and it can actually be achieved, then PNE is a good option, again with overheads. The other alternative is different PN spaces and keys per path (with shuffling or other low cost greasing algorithms) which has not yet been designed.

From: QUIC [mailto:[email-masked]] On Behalf Of Mike Bishop
Sent: Tuesday, April 10, 2018 5:03 PM
To: Praveen Balasubramanian <[email-masked]>; Ryan Hamilton <[email-masked]>
Cc: Victor Vasiliev <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: RE: Simple transform for improving PN ossification prevention

To: Ryan Hamilton <[email-masked]<mailto:[email-masked]>>

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 11 Apr 2018 10:55:40 +0900

2018-04-11 7:36 GMT+09:00 Praveen Balasubramanian
<pravb=[email-masked]>:
> No I am not concerned. Also it is speculation that a middlebox can actually
> do this with the shuffle scheme where each implementation is free to pick
> the PRNG, the shuffle algorithm, and change it over time. Implementations
> can also seed the PRNG for each connection.
>
>
>
> Middleboxes need to operate at line rate and cannot do any expensive
> operations and any guessed reordering will make things even worse
> performance wise.

I am not sure if that assumption is correct.

IIUC, there is a strong incentive to create a middlebox that reduces
retransmissions in the mobile networks, since it enables mobile
operators to have more customers connected to each base station. For
example, https://www.sandvine.com/hubfs/downloads/archive/whitepaper-tcp-optimization-opportunities-kpis-and-considerations.pdf
p. 13 claims 5% network efficiency gain by middleboxes intervening TCP
retransmissions.

It makes me understand that there is certain amount of money on table
that could be enough to do complicated things in the middlebox.

Note also that people working on such optimizations have the incentive
to take advantage of every aspect of how the majority of the QUIC
traffic they see look like, rather than respecting what the senders
are theoretically allowed to do.

> An obnoxious middlebox can always drop all QUIC traffic
> and force fallback to TCP.

Yes.

I believe that the signal that we need to send to people interesting
in "optimizing" QUIC in the middle is that they should either decide
not to (by possibly dropping QUIC entirely), or to cooperate with the
protocol designers in optimizing QUIC for their needs without causing
ossification.

IMO PNE is a good signal in that respect.

> One can construct bad middlebox behavior on a
> wide spectrum. One can also design ossification prevention solutions that
> make endpoints do either very little work or a lot of work. There are
> trade-offs.
>
>
>
> The goal here was to explore a low CPU cost transform that can do better
> greasing of the field with no monotonic increase, specifically to prevent
> dumb middleboxes from treating the nonce as a sequence number.
>
>
>
> On Tue, Apr 10, 2018 at 9:37 AM, Praveen Balasubramanian
> <pravb=[email-masked]> wrote:
>

-- 
Kazuho Oku

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 11 Apr 2018 10:55:40 +0900

Yes.

-- 
Kazuho Oku

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Wed, 11 Apr 2018 09:16:26 +0200

hi Kazuho, all,

> On 11 Apr 2018, at 03:55, Kazuho Oku <[email-masked]> wrote:
> 

That such middleboxes will emerge for QUIC, though, is an assumption that is (1) not testable and (2) IMO not credible. The analogy to TCP ossification is a compelling one, but one must remember that *all* of these features emerged to operate on TCP traffic because they improved performance in the cases for which they were deployed. The problem only emerges because (1) the Internet is global, and paths may also contain links for which the optimizations are harmful to performance or correct operation and/or (2) they interfere with attempts to change the stack at the endpoints.

> are theoretically allowed to do.

The assumption that such middleboxes will emerge for QUIC requires that there be an in-network operation that a middlebox can do involving manipulating the packet stream based on the packet number that will improve performance in local testing under some network conditions. If that is the case, we have not designed the protocol correctly. I don't think it will be: reordering-correction causes HoL, which shows up in the performance numbers. Attempts at ACK coalescing will reduce total throughput by inducing lost frames. So even in initial prototyping these functions will appear locally inferior.

If people want to deploy stuff on their networks that reduces performance for their customers, we as protocol designers cannot stop them. But here I think local (networks that work) and global (networks that aren't ossified) interests align nicely... IOW the "minority" of flows that packet stream manipulation will noticeably degrade is a big enough minority that it gets noticed.

IMO the only credible packet stream modification function which could emerge based on a packet number with known semantics is "window correction"; i.e. an attempt to reject UDP garbage that looks kind of like QUIC by analyzing the "window" of allowable packet numbers, and dropping packets outside that window. Packet number discontinuities would break this one, too, but I can see that "feature" making it past the alpha stage, at least. If that's the failure model, I'll note that schemes that permute the low bits while keeping the high bits won't defend well against it...

> protocol designers in optimizing QUIC for their needs without causing

I agree with this statement completely.

> IMO PNE is a good signal in that respect.

If the signal you mean here is "hello middlebox, the packet number is not for you", then I tend to agree. I think we should find the best tradeoff between implementation/runtime/deployability cost and ability to send that signal.

Cheers,

Brian

---

From: Roberto Peon <[email-masked]>
Date: Wed, 11 Apr 2018 07:52:47 +0000

++ Kazuho's observation that there is incentive to be helpful. I can't think of any of the ossification we ran into with TCP that wasn't done with the intent to be helpful/provide value. It probably did achieve that short-term, at the cost of much long-term value.
-=R

On 4/10/18, 6:56 PM, "QUIC on behalf of Kazuho Oku" <[email-masked] on behalf of [email-masked]> wrote:

    
    example, https://urldefense.proofpoint.com/v2/url?u=https-3A__www.sandvine.com_hubfs_downloads_archive_whitepaper-2Dtcp-2Doptimization-2Dopportunities-2Dkpis-2Dand-2Dconsiderations.pdf&d=DwIFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=e6gN5HMXP7H1jvcwvLbGUPjcv8oDMqad8xa-X0qhvKw&s=she78BMeOwK4eqR3IDUdZDsS7J1E55Cmz9LmR8TDMdo&e=

    
    
    Yes.

    

    -- 
    Kazuho Oku

---

From: Roberto Peon <[email-masked]>
Date: Wed, 11 Apr 2018 07:52:47 +0000

Yes.

    

    -- 
    Kazuho Oku

---

From: "Fossati, Thomas (Nokia - GB/Cambridge)" <[email-masked]>
Date: Wed, 11 Apr 2018 08:09:15 +0000

Sure, Brian has a very good point though: with integrity protection all over the place, an "useful" middle-box has very limited room for manoeuvre.  Take a look at RFC 3449 and search for "IPsec AH" to get an idea of the impact on the ability to implement "useful features" in the middle when the streams are integrity protected - let alone when they are encrypted.
Ossification-wise the advantage we get from PNE seems marginal (~0?) over the big win which already comes from AEAD.

On 11/04/2018, 08:53, "QUIC on behalf of Roberto Peon" <[email-masked] on behalf of [email-masked]> wrote:

    

    

    Yes.

    

    -- 
    Kazuho Oku

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 11 Apr 2018 17:41:17 +0900

Brian,

Thank you for your response. My comments inline.

2018-04-11 16:16 GMT+09:00 Brian Trammell (IETF) <[email-masked]>:
> That such middleboxes will emerge for QUIC, though, is an assumption that is (1) not testable and (2) IMO not credible.

I agree that it's not testable nor credible.

What I am arguing is that it is probable.

And assuming that it is probable, let's have PNE.

If we implement PNE, there would be no probability of PN becoming an
ossification point. Then, we will have the chance to reconsider.
However, if we decide not to have PNE and then see ossification, we
will no longer be able to change the protocol.

> The analogy to TCP ossification is a compelling one, but one must remember that *all* of these features emerged to operate on TCP traffic because they improved performance in the cases for which they were deployed.

What I am arguing is that the KPI of the middleboxes that optimize TCP
are not only the end-user-percieved performance, but also how
efficient the bandwidth is used.

It's true that with QUIC there will be much less "optimizations" that
middleboxes can make. But the bandwidth efficiency could still be
improvable, and mobile network operators will have the incentive to do
so since, as I stated, it helps them cram more users into each base
station.

And PN will likely be the vector being used for such optimizations
unless we encrypt it.

> The problem only emerges because (1) the Internet is global, and paths may also contain links for which the optimizations are harmful to performance or correct operation and/or (2) they interfere with attempts to change the stack at the endpoints.
>

I agree.

-- 
Kazuho Oku

---

From: Roberto Peon <[email-masked]>
Date: Wed, 11 Apr 2018 08:41:51 +0000

"obvious" avenues of (mis)use: reorder, block, delay, inform NAT mappings, etc. 

While I'd hope that many of not all of these would not be done, I have little confidence that they will not be shown to have some improvement for some scenarios. NAT mapping in particular seems a point of potential "optimization" that leaves me feeling worried.

What about routers which may be attempting to provide "security" by examining the PNs (such, if they don't trust the implementation should resort to other options instead) to fingerprint things (how random are your shuffles? Where do you start from? How many bit), etc.

TBH, I'm more worried about the things we can't think of. CRIME was a good example of a failure of imagination on our part, and I think we should heed its lesson: The side channels matter too, and PN is arguable a side channel.
-=R

On 4/11/18, 1:09 AM, "QUIC on behalf of Fossati, Thomas (Nokia - GB/Cambridge)" <[email-masked] on behalf of [email-masked]> wrote:

    

    

        

        
        Yes.

        

        -- 
        Kazuho Oku

---

From: "Fossati, Thomas (Nokia - GB/Cambridge)" <[email-masked]>
Date: Wed, 11 Apr 2018 08:56:02 +0000

Hi Kazuho

> And PN will likely be the vector being used for such optimizations

I'm not aware of any technique that uses an untamperable PN to achieve
bandwidth optimisation.  The middlebox needs to be able to actively
manipulate the SEQ/ACK space - and maybe other things - to do that.
And this is already not possible in QUIC, which is why network equipment
vendors are mainly looking at AQM-based solutions.

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 11 Apr 2018 09:43:52 +0000

Hi,

(chair hat off)

> will no longer be able to change the protocol.

this nicely sums up my personal standpoint on why we should do PNE in v1.

Lars

---

From: Roland Zink <[email-masked]>
Date: Wed, 11 Apr 2018 11:58:36 +0200

> I agree with this statement completely.
May this lead to network ossification in order to avoid protocol 
ossification? If it would be only protocol designers it would be nice 
but there will be many existing protocol implementations and they will 
not change. New networks have to support it or they will fail.

Regards,
Roland

---

From: "Lubashev, Igor" <[email-masked]>
Date: Wed, 11 Apr 2018 15:21:25 +0000

> fingerprint things

There are many sources of signal for fingerprinting w/o PN (observable congestion control algo and settings, packet pacing, timings and packet size artifacts, handshake packet sizes, etc.).  We should not assume that just by improving on PN you move the needle a lot.  You do move it a little.  So the question must always be: "at what cost?"

I am worried about the occasional cavalier attitude to costs.  It may be difficult for us estimate the cost of a protocol feature, just like it is difficult to estimate the privacy or ossification risks.

Costs have a real effect on the performance, affordability, and availability of service for the end users.  If we are willing to risk imposing a tax on users to avoid a risk of something, we should analyze this trade-off carefully.

* Are we asking all Internet users to pay a tax to improve privacy?  Does the amount of the tax justify the amount of privacy benefits it buys?

* Are we asking all Internet users to pay a tax to reduce PN ossification?  Does the amount of the tax justify the added flexibility protocol designers might need in the future?

I do not know the answers to these questions, but these questions must be considered carefully.

- Igor

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Apr 2018 16:37:03 +0100

Hiya,

On 11/04/18 16:21, Lubashev, Igor wrote:
> * Are we asking all Internet users to pay a tax to improve privacy?
> Does the amount of the tax justify the amount of privacy benefits it
> buys?
I think that (and your other questions) are good things to
ponder, but I don't believe the questions above are really
answerable, at least not unless we can also answer the
opposite question ("Are we asking all Internet users to pay
a tax by not improving privacy?"), and I'm pretty sure I
at least don't know how to evaluate that question. Maybe
that's part of why this discussion is so tricky.

Personally, as a future user of QUIC (but not an implementer),
I'd really prefer that the WG prioritise privacy-friendly
mechanisms if at all possible, even if the direct benefits
aren't completely clear.

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Apr 2018 16:37:03 +0100

Hiya,

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Apr 2018 16:37:02 +0100

Hiya,

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Apr 2018 16:37:04 +0100

Hiya,

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Apr 2018 16:37:02 +0100

Hiya,

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Apr 2018 16:37:04 +0100

Hiya,

Cheers,
S.

---

From: "Lubashev, Igor" <[email-masked]>
Date: Wed, 11 Apr 2018 16:37:07 +0000

Yes, these are difficult questions, especially since most of the information is unknown, and we are to weigh estimates and risks against each other.  But this is especially important when so many things are uncertain to keep at least the questions we are answering clear.  Hence, I would consider "Are we asking all Internet users to pay a tax by not improving privacy?" to be not a clear question but a rhetorical one.  I meant "tax" in a very specific way -- the real-world _financial_ cost.  I specifically want to pose questions of trade-offs of financial costs vs. benefits (very valuable benefits to be sure).

- Igor

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Wednesday, April 11, 2018 11:37 AM
To: Lubashev, Igor <ilubashe=[email-masked]>; Roberto Peon <[email-masked]>; Fossati, Thomas (Nokia - GB/Cambridge) <[email-masked]>; Kazuho Oku <[email-masked]>; Praveen Balasubramanian <[email-masked]>
Cc: Victor Vasiliev <[email-masked]>; IETF QUIC WG <[email-masked]>; Ryan Hamilton <[email-masked]>
Subject: Re: Simple transform for improving PN ossification prevention

Hiya,

> Does the amount of the tax justify the amount of privacy benefits it 
I think that (and your other questions) are good things to ponder, but I don't believe the questions above are really answerable, at least not unless we can also answer the opposite question ("Are we asking all Internet users to pay a tax by not improving privacy?"), and I'm pretty sure I at least don't know how to evaluate that question. Maybe that's part of why this discussion is so tricky.

Personally, as a future user of QUIC (but not an implementer), I'd really prefer that the WG prioritise privacy-friendly mechanisms if at all possible, even if the direct benefits aren't completely clear.

Cheers,
S.

---

From: "Lubashev, Igor" <[email-masked]>
Date: Wed, 11 Apr 2018 16:37:07 +0000

- Igor

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Wednesday, April 11, 2018 11:37 AM
To: Lubashev, Igor <ilubashe=[email-masked]>; Roberto Peon <[email-masked]>; Fossati, Thomas (Nokia - GB/Cambridge) <[email-masked]>; Kazuho Oku <[email-masked]>; Praveen Balasubramanian <[email-masked]>
Cc: Victor Vasiliev <[email-masked]>; IETF QUIC WG <[email-masked]>; Ryan Hamilton <[email-masked]>
Subject: Re: Simple transform for improving PN ossification prevention

Hiya,

Cheers,
S.

---

From: Christian Huitema <[email-masked]>
Date: Wed, 11 Apr 2018 09:32:39 -0700

> mechanisms if at all possible, even if the direct benefits

Second that. Praveen and Igor are making a fine point about performance,
but in my book performance optimization should be done after we have the
agreed functionality going. So, I would see the following sequence:

1) Agree that we want to prevent PN tracking, middlebox shenanigans, and
ossification. I think we do have rough consensus on that.

2) Check in PR #1079 as a basic way to accomplish this now.

3) Study higher performance alternative and a negotiation mechanism later.

-- Christian Huitema

---

From: Praveen Balasubramanian <[email-masked]>
Date: Wed, 11 Apr 2018 17:06:23 +0000

Not just users, but web service providers are affected. As an implementer and someone who will need to convince workloads to adopt QUIC at scale, I have the view that we should minimize complexity and cost unless properly justified. Performance is going to be a key factor in getting adoption for this protocol. Whether we like It or not, HTTPS/QUIC will be judged against the stack HTTPS/TCP we have today. If 90+ percentile latency improvements come at a large CPU cost, the incentive to move away from TCP will be less. Same holds if more battery is spent loading web pages on low power devices. 

I thought this discussion was focused on ossification but if we are talking about privacy, it is a complex topic and then we need an adversarial model, possible attacks, and clearly list the trade-offs for getting marginal improvements in privacy. The more mechanisms we add for preventing leakage of side channel information, the more complex the implementations and the cost. 

Before we make endpoints add perf overhead, create problems for hardware implementations, just plain break network signaling and health scenarios that work with TCP today, and make no attempts to mitigate aggressive UDP NAT timeouts, let's justify why. Also solutions may not be universally applicable - what is needed on the Internet (and across multiple paths) is very different from what is needed in constrained networks like datacenters or private single admin domain networks. This is a general purpose transport - so IMO we need to define mechanisms that support a range of trade-offs and make policy recommendations.

-----Original Message-----
From: QUIC [mailto:[email-masked]] On Behalf Of Christian Huitema
Sent: Wednesday, April 11, 2018 9:33 AM
To: [email-masked]
Subject: Re: Simple transform for improving PN ossification prevention

On 4/11/2018 8:37 AM, Stephen Farrell wrote:

> Personally, as a future user of QUIC (but not an implementer), I'd 
> really prefer that the WG prioritise privacy-friendly mechanisms if at 
> all possible, even if the direct benefits aren't completely clear.

Second that. Praveen and Igor are making a fine point about performance, but in my book performance optimization should be done after we have the agreed functionality going. So, I would see the following sequence:

1) Agree that we want to prevent PN tracking, middlebox shenanigans, and ossification. I think we do have rough consensus on that.

-- Christian Huitema

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 11 Apr 2018 12:31:49 -0500

No hats, but ...

On Wed, Apr 11, 2018 at 12:06 PM, Praveen Balasubramanian <
pravb=[email-masked]> wrote:

> Not just users, but web service providers are affected. As an implementer
> and someone who will need to convince workloads to adopt QUIC at scale, I
> have the view that we should minimize complexity and cost unless properly
> justified. Performance is going to be a key factor in getting adoption for
> this protocol. Whether we like It or not, HTTPS/QUIC will be judged against
> the stack HTTPS/TCP we have today. If 90+ percentile latency improvements
> come at a large CPU cost, the incentive to move away from TCP will be less.
> Same holds if more battery is spent loading web pages on low power devices.
>
> I thought this discussion was focused on ossification but if we are
> talking about privacy, it is a complex topic and then we need an
> adversarial model, possible attacks, and clearly list the trade-offs for
> getting marginal improvements in privacy.

The thing I've wondered most about from threads in this space, is the
discussion about preventing linkages due to address changes as a result of
NAT rebinding, and what the concerns are, and how bad linking after NAT
rebinding would be, or would not be.

It's OK for me to have questions about discussions that QUIC WG has, and
I'm not asking for people to explain things to me - please, continue to do
the work you're doing - but I suspect that the clearer the points Praveen
listed (adversarial model, possible attacks, tradeoffs) are in documents
that QUIC puts forward for publication, the fewer questions will come up
during AD Evaluation, Last Call and review team reviews, and IESG
Evaluation.

FWIW, of course. Do the right thing.

Spencer

> The more mechanisms we add for preventing leakage of side channel
> information, the more complex the implementations and the cost.
>
> Before we make endpoints add perf overhead, create problems for hardware
> implementations, just plain break network signaling and health scenarios
> that work with TCP today, and make no attempts to mitigate aggressive UDP
> NAT timeouts, let's justify why. Also solutions may not be universally
> applicable - what is needed on the Internet (and across multiple paths) is
> very different from what is needed in constrained networks like datacenters
> or private single admin domain networks. This is a general purpose
> transport - so IMO we need to define mechanisms that support a range of
> trade-offs and make policy recommendations.
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 11 Apr 2018 12:31:49 -0500

No hats, but ...

Spencer

---

From: Christian Huitema <[email-masked]>
Date: Wed, 11 Apr 2018 11:34:24 -0700

On 4/11/2018 10:31 AM, Spencer Dawkins at IETF wrote:

> discussion about preventing linkages due to address changes as a
> result of NAT rebinding, and what the concerns are, and how bad
> linking after NAT rebinding would be, or would not be.

That's a good question, and it probably deserves its own thread.

I think we need to consider two kinds of migration: voluntary migration,
and NAT rebinding. I really want to support privacy for voluntary
migration. I doubt than we can do better than a best effort for NAT
rebinding.

An example of voluntary migration is the parking lot scenario, in which
the client will voluntarily migrate the connection from WiFi to cellular
as the WiFi signal fades away. The migration is voluntary, as the client
will actively decide to send packets from a different source address,
and possibly from a different source port. Involuntary migration happens
when something change in the network without the client's knowledge, and
packet start arriving to the server from a different IP and port. The
canonical example of that is NAT rebinding.

There is no question in my mind that we want to prevent linkability when
doing voluntary migration, and that means rotating the connection ID and
breaking PN linkability. But NAT rebinding is another matter. There are
many big arguments against expanding too much resource to specifically
increase NAT rebinding privacy:

* Most NAT rebinding happens without the client's knowledge, which
seriously limit mitigation capability.

* If the connection was using IPv6 instead of IPv4, in theory there
would be no NAT.

* In the case of residential NAT, only the port changes upon rebinding,
so linkability is obvious.

* If there is just a short interval between the old and new NAT
bindings, adversaries can use time based solutions to link the two
connection.

The proposal in the document is that clients may simulate a voluntary
migration when going out of quiescence. This seems like a reasonable
best effort approach. Most NAT rebinding occurs after connections have
been idle for some time. Since there is a long interval, adversaries
have a harder time using time stamps for linkability. In case of long
intervals, carrier grade NAT may have recycled both the address and the
port. And we need to grease the migration code path in servers and
clients, so we can just as well do that.

DKG pointed out that NAT rebinding also happens in mobile platforms,
such as a car roaming between various cells. The car network offers a
router + NAT service to devices inside the car. The router would be
getting a new IPv4 address at each new cell, and there would be
rebinding of any connection between internal devices and outside
servers. If the QUIC connection survived, the adversaries will be able
to deduce from traffic observation the successive locations of the
device. This seems bad. If internal devices new about the connection
changes, they could use the voluntary mechanisms. DKG argued that we
should have protection even if the devices don't know about the
migration, but the only practical solution is to rotate the connection
ID for every packet -- effectively, encrypt the connection ID. This is
not what we are debating now. I personally think that the mobile
platform issue should be solved with some cooperation of the mobile
router, so the devices can engage in voluntary migration.

-- Christian Huitema

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Apr 2018 21:12:24 +0100

Hiya,

On 11/04/18 17:37, Lubashev, Igor wrote:
> Yes, these are difficult questions, especially since most of the 
> information is unknown, and we are to weigh estimates and risks 
> against each other.  But this is especially important when so many 
> things are uncertain to keep at least the questions we are answering 
> clear.  Hence, I would consider "Are we asking all Internet users to 
> pay a tax by not improving privacy?" to be not a clear question but
> a rhetorical one.  

I took 'em as questions and not as rhetorical questions:-)

> I meant "tax" in a very specific way -- the 
> real-world _financial_ cost.  I specifically want to pose questions 
> of trade-offs of financial costs vs. benefits (very valuable
> benefits to be sure).

Again, there's the same problem - are you trying to measure the
financial benefits of privacy? Or are you trying to compare the
financial costs of (e.g. PNE) against some other measure of the
benefits of privacy? I'm still in a position where I don't know
how to make those comparisons.

So maybe yeah, you're right that we're better considering your
specific questions purely as rhetorical and try find other
questions that could be answered.

Cheers,
S.

> * Are we asking all Internet users to pay a tax to reduce PN 
> ossification?  Does the amount of the tax justify the added 
> flexibility protocol designers might need in the future?
> 
> 
> - Igor
> 
> 
> -----Original Message----- From: Stephen Farrell 
> [mailto:[email-masked]] Sent: Wednesday, April 11, 2018 
> 11:37 AM To: Lubashev, Igor <ilubashe=[email-masked]>; 
> Roberto Peon <[email-masked]>; Fossati, Thomas (Nokia - GB/Cambridge) 
> <[email-masked]>; Kazuho Oku <[email-masked]>;
> Praveen Balasubramanian <[email-masked]> Cc: Victor Vasiliev 
> <[email-masked]>; IETF QUIC WG <[email-masked]>; Ryan Hamilton 
> <[email-masked]> Subject: Re: Simple transform for improving PN 
> ossification prevention
> 
> 
> Hiya,
> 
>> Does the amount of the tax justify the amount of privacy benefits
>> it buys?
> I think that (and your other questions) are good things to ponder, 
> but I don't believe the questions above are really answerable, at 
> least not unless we can also answer the opposite question ("Are we 
> asking all Internet users to pay a tax by not improving privacy?"), 
> and I'm pretty sure I at least don't know how to evaluate that 
> question. Maybe that's part of why this discussion is so tricky.
> 
> really prefer that the WG prioritise privacy-friendly mechanisms if 
> at all possible, even if the direct benefits aren't completely 
> clear.
> 
> Cheers, S.
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Apr 2018 21:12:24 +0100

Hiya,

Cheers,
S.

---

From: "Lubashev, Igor" <[email-masked]>
Date: Wed, 11 Apr 2018 21:55:04 +0000

Stephen, I think I was not clear.  My apologies.

To compare the value of things, you certainly need to first convert the values to the same units.  Since on one hand we have a $ value (more CPUs, larger batteries, more base stations, costlier network troubleshooting, ...), it seems natural to convert everything to $.  (Of course, we can only hope for very rough T-shirt size approximations here.)

> financial benefits of privacy

Yes.  Or, better, "financial benefits of the incremental change in privacy during deliberate connection migration".  (Anything that is not worse than TLS1.3+TCP fits the Charter.)  We may as well decide that most people on the Internet are willing to pay (or would be willing to pay, if they knew better) a lot for every single bit of extra privacy from pervasive surveillance, so the costs are justified.  (Judging from people's current behavior patterns this does not seem to be true.)

Ditto for the financial benefits of preventing ossification of PNs.

- Igor

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Wednesday, April 11, 2018 4:12 PM
To: Lubashev, Igor <ilubashe=[email-masked]>; Lubashev, Igor <[email-masked]>; Roberto Peon <[email-masked]>; Fossati, Thomas (Nokia - GB/Cambridge) <[email-masked]>; Kazuho Oku <[email-masked]>; Praveen Balasubramanian <[email-masked]>
Cc: Victor Vasiliev <[email-masked]>; IETF QUIC WG <[email-masked]>; Ryan Hamilton <[email-masked]>
Subject: Re: Simple transform for improving PN ossification prevention

Hiya,

On 11/04/18 17:37, Lubashev, Igor wrote:
> pay a tax by not improving privacy?" to be not a clear question but a 
> rhetorical one.

> I meant "tax" in a very specific way -- the real-world _financial_ 
> cost.  I specifically want to pose questions of trade-offs of 
> financial costs vs. benefits (very valuable benefits to be sure).

Again, there's the same problem - are you trying to measure the financial benefits of privacy? Or are you trying to compare the financial costs of (e.g. PNE) against some other measure of the benefits of privacy? I'm still in a position where I don't know how to make those comparisons.

So maybe yeah, you're right that we're better considering your specific questions purely as rhetorical and try find other questions that could be answered.

Cheers,
S.

> <[email-masked]>; Kazuho Oku <[email-masked]>; Praveen 
> Balasubramanian <[email-masked]> Cc: Victor Vasiliev 
> I think that (and your other questions) are good things to ponder, but 
> I don't believe the questions above are really answerable, at least 
> not unless we can also answer the opposite question ("Are we asking 
> all Internet users to pay a tax by not improving privacy?"), and I'm 
> pretty sure I at least don't know how to evaluate that question. Maybe

---

From: "Lubashev, Igor" <[email-masked]>
Date: Wed, 11 Apr 2018 21:55:04 +0000

- Igor

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Wednesday, April 11, 2018 4:12 PM
To: Lubashev, Igor <ilubashe=[email-masked]>; Lubashev, Igor <[email-masked]>; Roberto Peon <[email-masked]>; Fossati, Thomas (Nokia - GB/Cambridge) <[email-masked]>; Kazuho Oku <[email-masked]>; Praveen Balasubramanian <[email-masked]>
Cc: Victor Vasiliev <[email-masked]>; IETF QUIC WG <[email-masked]>; Ryan Hamilton <[email-masked]>
Subject: Re: Simple transform for improving PN ossification prevention

Hiya,

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Apr 2018 23:14:26 +0100

Hiya,

On 11/04/18 22:55, Lubashev, Igor wrote:
> To compare the value of things, you certainly need to first convert
> the values to the same units.  Since on one hand we have a $ value
> (more CPUs, larger batteries, more base stations, costlier network
> troubleshooting, ...), it seems natural to convert everything to $.
> (Of course, we can only hope for very rough T-shirt size
> approximations here.)
> 
> 
> Yes.  Or, better, "financial benefits of the incremental change in
> privacy during deliberate connection migration".  

So I've no idea how one might go about doing that without
stripping the term privacy of most of it's meaning. Nor do
I think it'd be particularly worthwhile trying tbh. OTOH,
you do give me the always-worthwhile opportunity to quote
Oscar Wilde: "Nowadays people know the price of everything
and the value of nothing." :-)

But if you do attempt to work that out, I'd be interested
in seeing what you come up with. Mind you that'd likely be
better off-list as I think we'd be wandering pretty far from
the WG's remit when we end up inevitably debating whether
Oscar was right or not.

S.

PS: Don't take this as me arguing for inefficiency wrt PNE,
I'm only arguing here about your suggested approach for
trying to analyse the trade-offs related to PNE.

> (Anything that is
> not worse than TLS1.3+TCP fits the Charter.)  We may as well decide
> that most people on the Internet are willing to pay (or would be
> willing to pay, if they knew better) a lot for every single bit of
> extra privacy from pervasive surveillance, so the costs are
> justified.  (Judging from people's current behavior patterns this
> does not seem to be true.)
> 
> 4:12 PM To: Lubashev, Igor <ilubashe=[email-masked]>;
> Lubashev, Igor <[email-masked]>; Roberto Peon <[email-masked]>;
> Fossati, Thomas (Nokia - GB/Cambridge) <[email-masked]>;
> Kazuho Oku <[email-masked]>; Praveen Balasubramanian
> <[email-masked]> Cc: Victor Vasiliev <[email-masked]>; IETF
> QUIC WG <[email-masked]>; Ryan Hamilton <[email-masked]> Subject: Re:
> Simple transform for improving PN ossification prevention
> 
> 
> Hiya,
> 
>>  things are uncertain to keep at least the questions we are
>> answering clear.  Hence, I would consider "Are we asking all
>> Internet users to pay a tax by not improving privacy?" to be not a
>> clear question but a rhetorical one.
> 
> benefits of privacy? I'm still in a position where I don't know how
> to make those comparisons.
> 
> specific questions purely as rhetorical and try find other questions
> that could be answered.
> 
> Cheers, S.
> 
>> 
>> 11:37 AM To: Lubashev, Igor
>> <ilubashe=[email-masked]>; Roberto Peon
>> <[email-masked]>; Fossati, Thomas (Nokia - GB/Cambridge) 
>>> * Are we asking all Internet users to pay a tax to improve
>>> privacy? Does the amount of the tax justify the amount of privacy
>>> benefits it buys?
>>  really prefer that the WG prioritise privacy-friendly mechanisms
>> if at all possible, even if the direct benefits aren't completely
>> clear.
>> 
>> Cheers, S.
>>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Apr 2018 23:14:26 +0100

Hiya,

S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Apr 2018 23:14:26 +0100

Hiya,

S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Apr 2018 23:14:26 +0100

Hiya,

S.

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 12 Apr 2018 10:44:09 +0900

2018-04-11 17:56 GMT+09:00 Fossati, Thomas (Nokia - GB/Cambridge)
<[email-masked]>:
> bandwidth optimisation.

Well, assuming that the majority of the senders will use PN in a
monotonously increasing manner and that skips will be inserted
infrequently, and assuming that such senders will implement ACK-based
loss detection, I would anticipate that it would make sense for a
middlebox to reorder the packet by the PN (by buffering out-of-order
packets for up to some short amount of time (e.g., 1/16 RTT)), since
it would reduce the probability of fast retransmits that could be
spurious.

I am not sure how effective doing so would be, or what the side
effects of doing that would be (or if such side effects can be
fixed)...

Am I missing something?

And anyways, let me assert what Roberto said. There will be many ways
of misusing a signal in the ways that we cannot expect of.

Let's start from the safe side (by having PNE) instead of exposing us
to the risk of ossification that will become unfixable once we start
seeing them.

> The middlebox needs to be able to actively

-- 
Kazuho Oku

---

From: Martin Thomson <[email-masked]>
Date: Thu, 12 Apr 2018 12:01:24 +1000

I don't know how realistic DKG's scenario is.  Most of these systems
aim to provide continuity of addressing because to do otherwise makes
the most common applications break all the time.  That means hiding
the consequences of handovers in the network, likely at great expense.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 12 Apr 2018 12:17:44 +1000

> it would reduce the probability of fast retransmits that could be

While it might seem like the latency hit here would be noticeable and
thus this optimization would be obviously undesirable, consider a
network operator that has to trade off between peak hour utilization
and latency.  If this little bit of HoLB gets their efficiency numbers
up by reducing retransmissions, maybe they will consider that a good
trade.

The other point is that in TLS, we have direct experience with
middleboxes "policing" the protocol.  That is, if it doesn't look like
TLS, the flow is stopped.  We know for sure that this includes
checking the record header, which means that TLS 1.3 uses 3 more
octets per record than it needs to.  It also includes a whole bunch of
handshake fields as well, which we have less information on as a
whole.  Even if we discount the QUIC==7 fiasco as aberrant, this is a
cost I'd rather not have to worry about paying some time in the
future.

So, from my perspective, in addition to the privacy "intangibles" that
Christian and Stephen have talked about, there is a real defensive
value in this.  That's without considering that we've already decided
that voluntary migration is a feature we need to have.

---

From: "Roni Even (A)" <[email-masked]>
Date: Thu, 12 Apr 2018 06:16:39 +0000

Hi Christian,
On the voluntary migration, what about when walking from the parking lot towards the house, will connect to Wifi and the IP address of the home router will probably be the same as when going out.  There will suddenly be a lot of traffic from the home router (not only QUIC), for example synchronizing all applications that were defined to download only on wifi. The migration will be easy to spot in this case.
Roni

-----Original Message-----
From: QUIC [mailto:[email-masked]] On Behalf Of Christian Huitema
Sent: Wednesday, April 11, 2018 9:34 PM
To: Spencer Dawkins at IETF
Cc: [email-masked]
Subject: Migration privacy and NAT rebinding

I think we need to consider two kinds of migration: voluntary migration, and NAT rebinding. I really want to support privacy for voluntary migration. I doubt than we can do better than a best effort for NAT rebinding.

An example of voluntary migration is the parking lot scenario, in which the client will voluntarily migrate the connection from WiFi to cellular as the WiFi signal fades away. The migration is voluntary, as the client will actively decide to send packets from a different source address, and possibly from a different source port. Involuntary migration happens when something change in the network without the client's knowledge, and packet start arriving to the server from a different IP and port. The canonical example of that is NAT rebinding.

There is no question in my mind that we want to prevent linkability when doing voluntary migration, and that means rotating the connection ID and breaking PN linkability. But NAT rebinding is another matter. There are many big arguments against expanding too much resource to specifically increase NAT rebinding privacy:

* Most NAT rebinding happens without the client's knowledge, which seriously limit mitigation capability.

* If the connection was using IPv6 instead of IPv4, in theory there would be no NAT.

* In the case of residential NAT, only the port changes upon rebinding, so linkability is obvious.

* If there is just a short interval between the old and new NAT bindings, adversaries can use time based solutions to link the two connection.

The proposal in the document is that clients may simulate a voluntary migration when going out of quiescence. This seems like a reasonable best effort approach. Most NAT rebinding occurs after connections have been idle for some time. Since there is a long interval, adversaries have a harder time using time stamps for linkability. In case of long intervals, carrier grade NAT may have recycled both the address and the port. And we need to grease the migration code path in servers and clients, so we can just as well do that.

DKG pointed out that NAT rebinding also happens in mobile platforms, such as a car roaming between various cells. The car network offers a router + NAT service to devices inside the car. The router would be getting a new IPv4 address at each new cell, and there would be rebinding of any connection between internal devices and outside servers. If the QUIC connection survived, the adversaries will be able to deduce from traffic observation the successive locations of the device. This seems bad. If internal devices new about the connection changes, they could use the voluntary mechanisms. DKG argued that we should have protection even if the devices don't know about the migration, but the only practical solution is to rotate the connection ID for every packet -- effectively, encrypt the connection ID. This is not what we are debating now. I personally think that the mobile platform issue should be solved with some cooperation of the mobile router, so the devices can engage in voluntary migration.

-- Christian Huitema

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 12 Apr 2018 08:23:11 +0200

Hi Christian,

On Wed, Apr 11, 2018 at 11:34:24AM -0700, Christian Huitema wrote:
(...)
> router, so the devices can engage in voluntary migration.

First, thanks for the long detailed explanation. To be honest, I'm not
much convinced that this rebinding will really happen often in the case
of the car network described above, as it would provide a terrible
experience to users inside the car and it's in the carrier's interest
not to break the end-to-end connectivity. At 130 km/h on a highway
you'd switch to a new tower roughly every ~2 minutes (4km).

Now regarding what you mention about the cooperation of the mobile router,
that makes me think about TCP ECN where intermediary routers may mark the
packets to signal certain conditions. That's a perfect example of why we
need to ensure that it *is* possible within certain limits to let the
network understand a stream and mark it. If we make sure the router cannot
recognize connections or needs to do very complex stuff to be able to just
decrypt a connection ID, we'll hardly get a good cooperation from such
equipments. And in my opinion in 2018 it wouldn't seem stupid to have a
"handover" bit in a transport protocol to signal that something changed
in the path and that both ends might have something to do (change an ID,
resend a packet to be sure to reopen a NAT flow, etc).

Willy

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Thu, 12 Apr 2018 00:02:56 -0700

So if a certain PN permutation scheme were deployed, even light middle
boxes could use this to classify the stream as QUIC connection and
immediately ossify away any future QUIC versions. It just need to do some
simple standard deviance on the for a given tuple.

I’d say we either need a clean incremental PN stream per path, or an
encrypted PN that is not breakable.

Mikkel

On 12 April 2018 at 04.17.56, Martin Thomson ([email-masked])
wrote:

---

From: Roland Zink <[email-masked]>
Date: Thu, 12 Apr 2018 11:01:43 +0200

In GPRS, UMTS or LTE networks wireless devices do not get new IP 
addresses when there is a handover between cells.  The packets are 
tunneled via GTP-U to the cells. However the path is changed (between 
SGW and eNB in LTE) and this may cause for example reordering of packets 
or no transmission of packets during the handover. Note that the 
throughput also changes between near and far cell conditions. The QUIC 
developers will need to handle this in their congestion avoidance 
algortihms.

Regards,

Roland

---

From: Martin Thomson <[email-masked]>
Date: Thu, 12 Apr 2018 19:05:16 +1000

> encrypted PN that is not breakable.

The clean per-path packet number doesn't defend against "helpfulness"
of the nature I described.  Those problems exist if the signal exists
at all.

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Thu, 12 Apr 2018 03:52:17 -0700

On 12 April 2018 at 11.05.17, Martin Thomson ([email-masked])
wrote:

True. But these are still the options as I see it. Half-baked obfuscation
will only make it worse.

There is the holy grail of fast 32-bit permutations that can be used
directly as IV, which are sufficiently safe wrt. privacy, and where the
permutation does not depend on the packet content.

The following function is useful to disperse a low-quality hash - it is a
perfect permutation. Unfortunately, or fortunately, it can be trivially
reversed - see stack overflow article. There are also 64-bit variants, and
it could also be just a single multiplication. Martin T. already hinted at
something similar in an earlier mail.

The benefit of this over lower octet permutation is that stupid
middle-boxes don’t have a chance, while slightly intelligent middle-boxes
can use it is loss / reordering signal, and QUIC hardware offload
decryptors can use the value unmodified as IV rather than computing the
inverse first. From a privacy perspective this is no better than plain
sequential numbers.

But it still serves as fingerprinting a given QUIC version. I’d say full
encryption or clear text sequential are the only viable choices.

    /* http://stackoverflow.com/a/12996028 */

    uint32_t x = type_hash;

    x = ((x >> 16) ^ x) * 0x45d9f3bUL;

    x = ((x >> 16) ^ x) * 0x45d9f3bUL;

    x = ((x >> 16) ^ x);

    return x;

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 12 Apr 2018 08:39:23 -0500

> On the voluntary migration, what about when walking from the parking lot towards the house, will connect to Wifi and the IP address of the home router will probably be the same as when going out.…

I'm not sure what point you're trying to make, here.  A flurry of traffic from
a residential IP address would probably indicate that a device has returned to
that network after an absence, sure, but how does the attacker know whether
that device was asleep while it was gone, or had some other (cell) connectivity?
And how does this flurry of activity help the attacker correlate the (connections
of the) device returning to the wifi network with the (connections of the) device
on some other network?

-Ben

---

From: Roland Zink <[email-masked]>
Date: Thu, 12 Apr 2018 16:00:43 +0200

> that device was asleep while it was gone, or had some other (cell) connectivity?
Assuming there is a difference between new connections and migrating 
connections then you can discover if a device was asleep if most of the 
connections are newly established. If you have enough power then you may 
even get the position / cell of the device, e.g. you may also be able to 
match the location.

> of the) device returning to the wifi network with the (connections of the) device
To match the previous connections you have the time and the destination 
address / port. If there are two to the same server then you probably 
can't distinguish between them immediately. The set of open connections 
is probably a good fingerprint of the device.

Roland

---

From: Praveen Balasubramanian <[email-masked]>
Date: Thu, 12 Apr 2018 16:16:20 +0000

I agree that there is a potential problem with monotonic increase. Making it a non-monotonic increase however doesn’t have to go all the way to encryption. For example with the shuffle scheme, PN cannot be treated as a sequence number since middlebox does not know the offsets in the encrypted portion of the header. 

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Wednesday, April 11, 2018 7:18 PM
To: Kazuho Oku <[email-masked]>
Cc: Fossati, Thomas (Nokia - GB/Cambridge) <[email-masked]>; Victor Vasiliev <[email-masked]>; Brian Trammell (IETF) <[email-masked]>; IETF QUIC WG <[email-masked]>; Ryan Hamilton <[email-masked]>; Praveen Balasubramanian <[email-masked]>
Subject: Re: Simple transform for improving PN ossification prevention

On Thu, Apr 12, 2018 at 11:44 AM, Kazuho Oku <[email-masked]> wrote:
>> I'm not aware of any technique that uses an untamperable PN to 
>> achieve bandwidth optimisation.
>

While it might seem like the latency hit here would be noticeable and thus this optimization would be obviously undesirable, consider a network operator that has to trade off between peak hour utilization and latency.  If this little bit of HoLB gets their efficiency numbers up by reducing retransmissions, maybe they will consider that a good trade.

The other point is that in TLS, we have direct experience with middleboxes "policing" the protocol.  That is, if it doesn't look like TLS, the flow is stopped.  We know for sure that this includes checking the record header, which means that TLS 1.3 uses 3 more octets per record than it needs to.  It also includes a whole bunch of handshake fields as well, which we have less information on as a whole.  Even if we discount the QUIC==7 fiasco as aberrant, this is a cost I'd rather not have to worry about paying some time in the future.

So, from my perspective, in addition to the privacy "intangibles" that Christian and Stephen have talked about, there is a real defensive value in this.  That's without considering that we've already decided that voluntary migration is a feature we need to have.

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Thu, 12 Apr 2018 09:21:57 -0700

It was pointed out to me that there is indeed an encryption scheme based on
a permutation such as the one I sent earlier modified so a key is xor’ed in
the mix. This makes 32-bit or 64-bit encryption is possible without
depending on packet content, and hence the encrypted result can be used as
IV directly.

It might not be hard enough to truly secure privacy, but balanced against
all other leaks it could be workable. The encrypted PN can be used as IV
directly.

This should be compared to doing just a few AES rounds encrypting the AEAD
tag and then xor that with PN. This is faster than the full 10 round and
most processors support single round AES in hardware these days. It is
likely just as fast as a 32-bit xor multiply scheme.

Both schemes only use the actual size of the PN.

The main difference between the two is that packet decryption with the AES
scheme cannot take place before PN has been decrypted while this is not the
case with 32-bit crypto. Likewise, encryption can start before the full
content is known(*) when using 32-bit crypto.

(*) with the new length field introduced, it is not possible to encrypt on
the fly - at least not the Authenticated Data part - but this only apply to
the initial handshake.

Kind Regards,
Mikkel Fahnøe Jørgensen

On 12 April 2018 at 12.52.17, Mikkel Fahnøe Jørgensen ([email-masked])
wrote:

    uint32_t x = type_hash;

    x = ((x >> 16) ^ x);

    return x;

---

From: Praveen Balasubramanian <[email-masked]>
Date: Thu, 12 Apr 2018 16:28:51 +0000

Re. #1079, following seems like a way forward so we get to do some implementations and get data:

  1.  PN transform is negotiated using transport params.
  2.  Following PN transforms are supported:
     *   PNE

Connections expecting to use multiple paths due to gratuitous/voluntary migration MUST negotiate and use PNE transform. See issue 1271 where options are being discussed on how migration could be negotiated.

Revisit this solution for proper multi-path after designing multiple PN spaces. I am fine if this is done for V2.

     *   Low cost ossification prevention transform (like shuffle).

For connections on the Internet on single path require them to negotiate this transform. Even better if we find another low cost scheme with better properties before we ship V1.

     *   No-op (current draft)

For intra-datacenter or single domain private network scenarios allow usage of the no-op transform.

If server fails to negotiate PNE and supplies multiple connection IDs for migration, client fail the connection.
If the server fails to negotiate a low cost transform on the Internet, client fails the connection.

Please note that servers are free to pick PNE all the time. This allows server deployments which have no performance concern to always use PNE. I do have some battery life concerns on client side, but I do think the major perf concern is on server side.

If the deployments using low cost transform hit middlebox issues they will suffer and pay the cost to do PNE.

From: Mikkel Fahnøe Jørgensen [mailto:[email-masked]]
Sent: Thursday, April 12, 2018 3:52 AM
To: Martin Thomson <[email-masked]>
Cc: IETF QUIC WG <[email-masked]>; Brian Trammell (IETF) <[email-masked]>; Ryan Hamilton <[email-masked]>; Victor Vasiliev <[email-masked]>; Fossati, Thomas (Nokia - GB/Cambridge) <[email-masked]>; Kazuho Oku <[email-masked]>; Praveen Balasubramanian <[email-masked]>
Subject: Re: Simple transform for improving PN ossification prevention

On 12 April 2018 at 11.05.17, Martin Thomson ([email-masked]<mailto:[email-masked]>) wrote:
The clean per-path packet number doesn't defend against "helpfulness"
of the nature I described. Those problems exist if the signal exists
at all.

True. But these are still the options as I see it. Half-baked obfuscation will only make it worse.

There is the holy grail of fast 32-bit permutations that can be used directly as IV, which are sufficiently safe wrt. privacy, and where the permutation does not depend on the packet content.

The following function is useful to disperse a low-quality hash - it is a perfect permutation. Unfortunately, or fortunately, it can be trivially reversed - see stack overflow article. There are also 64-bit variants, and it could also be just a single multiplication. Martin T. already hinted at something similar in an earlier mail.

The benefit of this over lower octet permutation is that stupid middle-boxes don’t have a chance, while slightly intelligent middle-boxes can use it is loss / reordering signal, and QUIC hardware offload decryptors can use the value unmodified as IV rather than computing the inverse first. From a privacy perspective this is no better than plain sequential numbers.

But it still serves as fingerprinting a given QUIC version. I’d say full encryption or clear text sequential are the only viable choices.

    /* http://stackoverflow.com/a/12996028<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fstackoverflow.com%2Fa%2F12996028&data=02%7C01%7Cpravb%40microsoft.com%7Ca2c88dcbb1514646489e08d5a0637623%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636591271404538121&sdata=VA8DpVcyhVKyWOMKScnhomUQySGb9q3x1rdYKsctwf0%3D&reserved=0> */

    uint32_t x = type_hash;

    x = ((x >> 16) ^ x);

    return x;

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 12 Apr 2018 13:08:14 -0500

> connections are newly established. If you have enough power then you may

If I have my phone set to "wifi-only" for a bunch of services, I wonder
whether those would show up as new connections or continuing ones when
I come back on wifi.

> even get the position / cell of the device, e.g. you may also be able to

True, but there's a potentially pretty big difference in attacker capabilities
between just snooping on the residential ISP and also having cell-level
visibility into the wireless carrier's network.  Certainly there are some
attackers who can do both, but is there an order-of-magnitude difference from
those only able to do one?

> address / port. If there are two to the same server then you probably can't
> distinguish between them immediately. The set of open connections is
> probably a good fingerprint of the device.

As was mentioned in the other subthread, the server address/port may not have
much information value, but sure, the set of open connections probably has
usable fingerprinting value.

Thanks,

Ben

---

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 13 Apr 2018 13:44:40 +0200

+1 if QUIC doesn’t get deployed large-scale because the performance impact is too high for certain use case, or is blocked on many paths by middleboxes that prefer the traffic to fall back to TCP, then no user will benefit from any privacy improvements with build into quic.

> Am 11.04.2018 um 19:06 schrieb Praveen Balasubramanian <pravb=[email-masked]>:
>

---

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 13 Apr 2018 13:44:40 +0200

---

From: Praveen Balasubramanian <[email-masked]>
Date: Tue, 17 Apr 2018 19:09:42 +0000

I opened issue #1296<https://github.com/quicwg/base-drafts/issues/1296> for tracking PN transform negotiation.

From: QUIC [mailto:[email-masked]] On Behalf Of Praveen Balasubramanian
Sent: Thursday, April 12, 2018 9:29 AM
To: Mikkel Fahnøe Jørgensen <[email-masked]>; Martin Thomson <[email-masked]>
Cc: Ryan Hamilton <[email-masked]>; Fossati, Thomas (Nokia - GB/Cambridge) <[email-masked]>; Brian Trammell (IETF) <[email-masked]>; Victor Vasiliev <[email-masked]>; IETF QUIC WG <[email-masked]>; Kazuho Oku <[email-masked]>
Subject: RE: Simple transform for improving PN ossification prevention

     *   No-op (current draft)

From: Mikkel Fahnøe Jørgensen [mailto:[email-masked]]
Sent: Thursday, April 12, 2018 3:52 AM
To: Martin Thomson <[email-masked]<mailto:[email-masked]>>
Cc: IETF QUIC WG <[email-masked]<mailto:[email-masked]>>; Brian Trammell (IETF) <[email-masked]<mailto:[email-masked]>>; Ryan Hamilton <[email-masked]<mailto:[email-masked]>>; Victor Vasiliev <[email-masked]<mailto:[email-masked]>>; Fossati, Thomas (Nokia - GB/Cambridge) <[email-masked]<mailto:[email-masked]>>; Kazuho Oku <[email-masked]<mailto:[email-masked]>>; Praveen Balasubramanian <[email-masked]<mailto:[email-masked]>>
Subject: Re: Simple transform for improving PN ossification prevention

    uint32_t x = type_hash;

    x = ((x >> 16) ^ x);

    return x;

---

From: Praveen Balasubramanian <[email-masked]>
Date: Tue, 17 Apr 2018 19:09:42 +0000

*   No-op (current draft)

    uint32_t x = type_hash;

    x = ((x >> 16) ^ x);

    return x;