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

[Kazuho Oku <[e-mail]>]

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.

-- 
Kazuho Oku