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

[Kazuho Oku <[e-mail]>]

2018-04-06 12:48 GMT+09:00 Lubashev, Igor <[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]]
> *Received:* Thursday, 05 Apr 2018, 10:56PM
> *To:* Martin Thomson [[e-mail]]
> *CC:* Mirja Kühlewind [[e-mail]]; QUIC WG [
> [e-mail]]; Christian Huitema [[e-mail]]; Frederick Kautz [
> [e-mail]]
> *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]>:
>
>> On Fri, Apr 6, 2018 at 12:06 PM, Kazuho Oku <[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