Re: Explicit measurability in the QUIC wire image (was Re: Packet number encryption)

[Kazuho Oku <[e-mail]>]

2018-02-07 19:23 GMT+09:00 Mikkel Fahnøe Jørgensen <[e-mail]>:
>
> On 7 February 2018 at 11.10.21, Martin Thomson ([e-mail])
> wrote:
>
> I looked into these when I first considered packet number encryption.
>
> Hi Martin, I think you might be misreading the intention behind this
> sequence.
>
> The idea is to generate 1 bit for every packet sent on a specific path, in
> the order the packet was sent, not to encode packet numbers directly.

What Mikkel says.

Or put it another way, below is a short summary of the approaches
being proposed:

* encode couple of least significant bits of the per-path sequence
number ("a small-modulo sequence number") [1]
* encode one bit in the middle of the per-path sequence number [2]

When observing that one bit of [2] spanning across multiple packets
belonging to a particular path, it looks like a square wave. There
came out variations of the approach.

* use sin wave instead of square wave [3]
* use bitsteram of PI instead of square wave [4][5]
* use bitstream of xorshift+ instead of square wave [6]

I would argue that the approaches discussed in [2] to [6] are superior
to [1] due to the fact that they use less bits, expose less
information, while possibly given us reasonable observation of loss
and reorder rate.

[1] https://www.ietf.org/mail-archive/web/quic/current/msg03030.html
[2] https://www.ietf.org/mail-archive/web/quic/current/msg03146.html
[3] https://www.ietf.org/mail-archive/web/quic/current/msg03146.html
[4] https://www.ietf.org/mail-archive/web/quic/current/msg03156.html
[5] https://www.ietf.org/mail-archive/web/quic/current/msg03171.html
[6] https://www.ietf.org/mail-archive/web/quic/current/msg03186.html

> The
> encoding of packet numbers is a separate thing whether encrypted or
> otherwise.
>
> When an observer collects these bits into words from several packets, it is
> possible to compare the gathered string with the expected sequence.
>
> The random access is only needed for analytical purposes to know about
> packet loss in the network, not to operate the QUIC transport as such. If
> the sequence is fixed and repeats with reasonable cycle length, it can be
> done efficiently in hardware.
>
> It is true that if you sample, say 32 bits, the mapping is not bijective so
> if you match the sequence, it is ambiguous. But since you already know what
> to expect next and you can choose the sample length as long as you want, say
> 128 bits, you do get very good information about where loss and reordering
> happened. If the sequence was not random, you would not have this property.
>
> As to reverse engineering, packets are already sent in order, so learning
> what the original order was, is hardly a significant compromise, except if
> you have multiple connections on the same tuple without transmitting an
> observable connection ID.
>
>



-- 
Kazuho Oku