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

[Kazuho Oku <[e-mail]>]

2018-04-06 2:27 GMT+09:00 Mike Bishop <[e-mail]>:
> Spec says:
>
> An endpoint MUST NOT return to the send rate used for the previous path
> unless it is reasonably sure that the previous send rate is valid for the
> new path. For instance, a change in the client’s port number is likely
> indicative of a rebinding in a middlebox and not a complete change in path.
> This determination likely depends on heuristics, which could be imperfect;
> if the new path capacity is significantly reduced, ultimately this relies on
> the congestion controller responding to congestion signals and reducing send
> rates appropriately.
>
>
>
> You're not required to reset the CWND if you have reason to believe the
> underlying path is the same, so doing this shouldn’t cause any transport
> information to get reset.

Thank you for pointing that out. I missed that.

OTOH, I still wonder if frequent gratuitous migration is a good solution.

I'd assume that in case of users behind a large-scale NAT connecting
to a CDN, there would be many connections sharing the same client-IP,
server-IP, server-port. The only difference in the 5-tuple is the
clients' port.

If we require frequent gratuitous migration, wouldn't either the NAT
will run out of port addresses belonging to the same client-IP or
required to switch to a different IP address?

>
>
>
> -----Original Message-----
> From: QUIC [mailto:[e-mail]] On Behalf Of Kazuho Oku
> Sent: Thursday, April 5, 2018 10:19 AM
> To: Christian Huitema <[e-mail]>
> Cc: IETF QUIC WG <[e-mail]>; Mirja Kühlewind
> <[e-mail]>; Frederick Kautz <[e-mail]>
> Subject: Re: Privacy holes (was: Re: Getting to consensus on packet number
> encryption)
>
>
>
> 2018-04-06 1:08 GMT+09:00 Christian Huitema <[e-mail]>:
>
>>
>
>>
>
>>> 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.
>
>
>
> I agree that it might be a good idea to grease.
>
>
>
> OTOH I do not think that gratuitous migration would be a good solution due
> to performance issues. We would be required to start from INITCWND every
> time the client switches to a new address. The fact that we cannot run two
> paths simultaneously in QUIC v1 makes the performance drawback big.
>
>
>
> Rather, I'd prefer making handshake packets indistinguishable from short
> header packets. In essence, you move the flags of the long header inside the
> AEAD-protected area. An endpoint that receives a packet carrying a CID that
> does not belong to any known connection trial-decrypts the packet as a
> initial packet and handles it as a connection initiation, or sends a
> stateful reset if the trial-decryption fails.
>
>
>
>> -- Christian Huitema
>
>
>
>
>
>
>
> --
>
> Kazuho Oku
>
>



-- 
Kazuho Oku