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

[Martin Thomson <[e-mail]>]

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

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

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.

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.

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