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

[Kazuho Oku <[e-mail]>]

2018-04-06 17:36 GMT+09:00 Brian Trammell (IETF) <[e-mail]>:

>
>
> > On 6 Apr 2018, at 09:45, Martin Thomson <[e-mail]>
> wrote:
> >
> > We do have data about rate of binding creation, courtesy of tests done
> > for WebRTC.  In essence, bindings can be created at rates that exceed
> > most needs (I think that they went down to single digit milliseconds,
> > far lower than I think is relevant here).
>
> There are two relevant metrics here: binding creation rate and maximum
> concurrent state. The latter is where I expect there to be more
> variability, and potential unfortunate side effects of an engineering
> decision made with a single consideration. "People stuck behind marginal
> NATs outside their own control don't deserve to use QUIC" is not a great
> statement to make, even accidentally.
>
> > Justin Uberti has the numbers, but I struggled to find the email or
> > slides; we can ask if you care. This result differed from the data
> > that was available when STUN was first developed, where it was found
> > that there were non-trivial numbers of NAT devices that lost bindings
> > below 20ms (see https://tools.ietf.org/html/rfc5245#appendix-B.1).
>
> This is useful, thanks!
>
> > The question about exhaustion is relevant, I agree.  There, the value
> > doesn't need measurement as much as asking the right person what their
> > configuration is.  Take the number of ports open for bindings per IP,
> > the duration of a binding, and how many clients are expected to be
> > behind each IP address or how many bindings each client is limited to.
> > We'd probably need to just ask a few CGNAT operators; anything smaller
> > is unlikely to be as sensitive as something that runs at a decent
> > scale.  But getting data in the usual fashion - making bindings until
> > something breaks - might be a little antisocial.
>
> Agreed that CGNAT is where the highest pain magnitude will be, but there
> is a very long tail of CPE out there, where configuration information will
> be harder to come by. But that's why we have a TCP fallback, I guess.
>
> > If we're going to saturate NAT bindings with this, then a signal might
> > be a good solution.  Or it might just be that we can recommend a rate
> > limit on these little migrations.  Based on typical timeouts on UDP
> > (30s is very common, see also experience with ICE), we could say that
> > a little migration every 10s is OK and you only have each connection
> > taking 3 bindings.  That doesn't seem that bad.
>
> It's multiplicative by a factor of three, which means that the max flow
> concurrency will reduce by a factor of three. I agree it's probably
> tolerable, but we do need to understand what we're actually getting for
> that cost. I remain dubious about the actual privacy benefits WRT third
> party passive surveillance here -- they don't accrue at all unless there's
> a CGNAT in the way that doesn't bind an address/port range to a customer at
> a given point in time. In the common case, ISTM that just burn more
> in-network state than they additionally require at the surveillance point
> to track the change. Defenses with such scaling curves are not a good idea.
>

I think I share the same concern.

One way to minimize the impact could be to suggest certain amount of
connections (e.g., 5%) to gratuitously migrate to a new tuple just once,
right after the connection is being established.

If we specify that way, we can assume that the impact on the NAT will be
having 5% more flows. Middlebox vendor that mistakenly tries to use the
cleartext bits in the packet header as the signal of connection initiation
will also see failures at the same rate.


> Another issue this raises: this will wreak varying levels havoc on
> anything that uses IPFIX, NetFlow, sFlow, or similar technologies for
> accounting or forensics. For accounting, whether two flow records happen to
> represent the same flow is irrelevant, since they'll generally be dumped
> into larger aggregates anyway. Replacing a single long-lived flow (a common
> max active time is 30min) with its equivalent split into 10s windows will
> lead to a 180x increase in export bandwidth for these flows in the first
> stage of the collection infrastructure, but the flow counts handled by
> these infrastructures (when connected to the open Internet) are usually
> dominated by single-packet UDP and ICMP garbage anyway, so this probably
> won't have too terrible an impact.
>
> Most such infrastructures are sampled (sFlow explicitly so), and there are
> well-known issues with differential visibility of packet-sampled flows
> based on flow duration. QUIC flows rotating ports every 10s would be
> systematically undercounted with respect to long-duration TCP flows, which
> will provide a strong incentive for correction if it materially impacts
> settlement.
>
> Especially forensics for operational security will remain very interested
> in understanding whether a group of 5-tuple flows are related to the same
> activity. In most enterprise environments, though, any CGNAT mappings are
> reversable, so there will not necessarily be a strong incentive
>
> I want to like this proposal, but I'm increasingly left with the
> impression that this is neither a particularly useful nor a completely safe
> thing to do at scale.
>
> Cheers,
>
> Brian
>
> >
> > On Fri, Apr 6, 2018 at 5:16 PM, Brian Trammell (IETF) <[e-mail]>
> wrote:
> >> (Repeating and expanding my comment on #1269 to the list)
> >>
> >> +1 to CID rotation being pointless if we don't do this. However, this
> seems dangerous if not done carefully, and it links CID rotation rate to
> the maximum usable UDP port consumption rate, which is (most probably)
> widely variable across access networks and (AFAICT) largely unknown in the
> literature. We have anecdata here, and we need data.
> >>
> >> Note that QUIC presently doesn't have an advisory on-path state
> clearance signal (we hsd discussed this as a signal bound to public reset
> in #20, but it morphed into Stateless Reset, which has completely different
> semantics), which means that there is neither a present nor yet a potential
> future method to reduce the NAT state load this will generate.
> >>
> >> I'd feel a lot less apprehensive about this if there were an advisory,
> integrity-protected signal meant for path consumption to clear state for a
> path. Of course it wouldn't be used at all on day one, but the tradeoff it
> presents is "hey, this is QUIC, it will burn through your UDP port state
> faster than any other UDP protocol and multiplicatively faster than TCP;
> but hey look, you can clear state when you see this path-verifiable singal
> to reduce the impact this has."
> >>
> >> Cheers,
> >>
> >> Brian
> >>
> >>> On 6 Apr 2018, at 02:38, Martin Thomson <[e-mail]>
> wrote:
> >>>
> >>> 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
> >>>
> >>
>
>


-- 
Kazuho Oku