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

[Mikkel Fahnøe Jørgensen <[e-mail]>]

So eventually CID's will ossify into certain lenghts by convention to things working smoothly in the general case?

________________________________
From: QUIC <[e-mail]> on behalf of Kazuho Oku <[e-mail]>
Sent: Friday, April 6, 2018 6:02:23 AM
To: Lubashev, Igor
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: Privacy holes (was: Re: Getting to consensus on packet number encryption)



2018-04-06 12:48 GMT+09:00 Lubashev, Igor <[e-mail]<mailto:[e-mail]>>:
> The length of DCID can be a signal to the stateless load balancers.

Short headers do not have an explicit CID length, so we are back to validating the integrity of CID, no? What am I missing?

Yeah I missed that, apparently. Thank you for pointing that out.

So I would propose to encrypt the type bits _and_ have DCID length in the header in cleartext.

By doing that, it will still be possible for stateless load balancers to determine if a packet is initial (by checking if DCIL is 8) without decrypting the packet, at the same time being impossible for a middlebox to reliably determine the same thing (assuming that some servers will advertise DCID of 8 octets).



-----Original Message-----
From: Kazuho Oku [[e-mail]<mailto:[e-mail]>]
Received: Thursday, 05 Apr 2018, 10:56PM
To: Martin Thomson [[e-mail]<mailto:[e-mail]>]
CC: Mirja Kühlewind [[e-mail]<mailto:[e-mail]>]; QUIC WG [[e-mail]<mailto:[e-mail]>]; Christian Huitema [[e-mail]<mailto:[e-mail]>]; Frederick Kautz [[e-mail]<mailto:fkautz@alumni..cmu.edu>]
Subject: Re: Privacy holes (was: Re: Getting to consensus on packet number encryption)

Hi Martin,

Thank you for the response.. My comments inline.

2018-04-06 11:34 GMT+09:00 Martin Thomson <[e-mail]<mailto:[e-mail]>>:
On Fri, Apr 6, 2018 at 12:06 PM, Kazuho Oku <[e-mail]<mailto:[e-mail]>> wrote:
> 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.

Oh, I didn't get the same impression, but it does seem like a valid
concern.  The idea I had was to have clients migrate often enough that
those middleboxes will see those migrations and not incorrectly assume
that flows have to start with Initial packets.

Of course, migrating often like this might not provide enough
incentive to avoid that practice because clients will likely make new
connections when the old one fails.  But given that this sort of
failure probably involves a timeout before the repair, it's probably
still noticeable enough to generate support tickets (and incentive to
allow the migration to pass).

Existing middleboxes that pass UDP will be fine, so we at least have
that in our favour.

> 1. frequent gratuitous migration by clients, so that middlebox vendors can
> notice that there design is wrong prior to shipping it

That is what this was angling for.  The question being how frequent.

> 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.

It has been suggested a few times elsewhere.  The question is how far
you go: do you send Initial and Handshake packets that use the
handshake packet protection and carry apparently real ClientHello and
ServerHello messages?  Do you restrict the flow of packets to match
0-RTT?

> 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.

That is possible, but it depends on how often you attempt this.  CGNAT
does try to keep IP addresses for the same device stable.  If not,
then a congestion controller reset for relatively infrequent
migrations isn't so bad if heuristics fail.  It's only when you have
very frequent migration that the resets becomes burdensome.

How frequent is the issue here.

If it's too frequent, some NATs could run out of unassigned ports, and if depending on their eviction algorithm, shutdown UDP-based flows running other protocols that do not do gratuitous switching. Other NATs could start assigning new public addresses as they run out of unassigned ports.

If it's too infrequent, then the chance of seeing misimplemented middlebox becomes higher.


> 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.

Yeah, that's hard.  Having the load balancer hit the slow path for
every packet seems pretty fatal.

That was my understanding until I started to consider the impact of symmetric CIDs.

The length of DCID can be a signal to the stateless load balancers for distinguishing an initial packet. If people interested in using that type of load balancer can agree that they will be using CID other than 8 octets, the length can be used as the signal by them.

More detail about using DCID can be found on https://www.ietf.org/mail-archive/web/quic/current/msg03809.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_quic_current_msg03809.html&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=WsJaFd1M4_j4sdAutwoZzcMiZ8Ut8mmyHO9Jn0FAQOI&s=gTP2rfuzpXp0_GdcmG8aA_N4hlvaYnhj6H_CVyXBK10&e=>.

--
Kazuho Oku



--
Kazuho Oku