Re: Privacy holes (was: Re: Getting to consensus on packet number encryption)

[Kazuho Oku <[e-mail]>]

2018-04-06 9:38 GMT+09:00 Martin Thomson <[e-mail]>:

> On Fri, Apr 6, 2018 at 2:08 AM, Christian Huitema <[e-mail]>
> wrote:
> >> On Apr 5, 2018, at 8:58 AM, Frederick Kautz <[e-mail]>
> wrote:
> >>
> >> Are you concerned that middleware boxes may be trained to reject
> migrations, thereby forcing a new connection with a visible negotiation?
> >
> > Yes. Hence the need to grease. For example, have clients do some
> gratuitous migration to a new source port number rather frequently.
>
> This seems like a simple fix, particularly since Mike recently added
> text that suggests occasional use of new connection IDs.  In the
> spirit of keeping the wheels greased:
>
> https://github.com/quicwg/base-drafts/pull/1269
>
>
Would you mind explaining how you would solve the issue?

If I understand correctly, Christian's concern is that some middleboxes
might only create a hole if the first packet sent by a client (using a new
port) looks like a Initial packet.

Consider the case where you want to build a middlebox that allows QUIC, but
no other UDP-based protocols.

By observing the QUIC packets, you think that you can implement such a
middlebox by creating a hole only when the UDP flow starts with a packet
starting with 0xff (long header + Initial). But such a design will block
migration.

The question is if we need to address the issue proactively, and how.

FWIW, I can see at least three possible approaches here.

1. frequent gratuitous migration by clients, so that middlebox vendors can
notice that there design is wrong prior to shipping it
2. make long header packets not easily indistinguishable from short header
packets (by encrypting the type field)
3. mimic 0-RTT handshake when gratuitously switching to a new UDP flow
(depends on #1262)

1 and 2 have been discussed on this thread. I haven't yet seen 3 being
discussed.

The concerns so far being raised for 1 is that NATs might run out of
unassigned ports and that switching to a new path might trigger the restart
of congestion control on large-scale NATs that use multiple public
addresses.

The concern so far being raised for 2 is that stateless load balancers
would be required to decrypt the type field (or the entire packet,
depending on how we encrypt) to determine if a packet is trying to initiate
a new connection.

-- 
Kazuho Oku