Re: Privacy holes

[Ian Swett <[e-mail]>]

There's some slightly older data from QUIC on slide 10 in this IETF
presenation:
https://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf

TLDR: 90% of networks have at least a 1 minute timeout, but only 50% have
at least a 2 minute timeout.

On Fri, Apr 6, 2018 at 6:01 AM Roland Zink <[e-mail]> wrote:

>
> Am 06.04.2018 um 09:45 schrieb Martin Thomson:
>
> 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.
>
> I have found this :
>
> RFC 4787 Network Address Translation (NAT) Behavioral Requirements for
> Unicast UDP (https://tools.ietf.org/html/rfc4787#page-12):
>    REQ-5:  A NAT UDP mapping timer MUST NOT expire in less than two
>       minutes, unless REQ-5a applies.
>
>       a) For specific destination ports in the well-known port range
>          (ports 0-1023), a NAT MAY have shorter UDP mapping timers that
>          are specific to the IANA-registered application running over
>          that specific destination port.
>
> RFC6888 Common Requirements for Carrier-Grade NATs (CGNs):
>
>   REQ-8:  Once an external port is deallocated, it SHOULD NOT be
>       reallocated to a new mapping until at least 120 seconds have
>       passed, with the exceptions being:
>
>       a.  If the CGN tracks TCP sessions (e.g., with a state machine, as
>           in Section 3.5.2.2 of [RFC6146] <https://tools.ietf.org/html/rfc6146#section-3.5.2.2>), TCP ports MAY be reused
>           immediately.
>
>       b.  If external ports are statically assigned to internal
>           addresses (e.g., address X with port range 1000-1999 is
>           assigned to subscriber A, 2000-2999 to subscriber B, etc.),
>           and the assignment remains constant across state loss, then
>           ports MAY be reused immediately.
>
>       c.  If the allocated external ports used address-dependent or
>           address-and-port-dependent filtering before state loss, they
>           MAY be reused immediately.
>
>       The length of time and the maximum number of ports in this state
>       MUST be configurable by the CGN administrator.
>
>
>
> So assuming 30 seconds seems a bit short. When there would be signals for
> session start and end then NATs could track how long mappings are
> necessary. Avoiding that and creating many bindings may be unsocial.
>
>
> On Fri, Apr 6, 2018 at 5:16 PM, Brian Trammell (IETF) <[e-mail]> <[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]> <[e-mail]> wrote:
>
> On Fri, Apr 6, 2018 at 2:08 AM, Christian Huitema <[e-mail]> <[e-mail]> wrote:
>
> On Apr 5, 2018, at 8:58 AM, Frederick Kautz <[e-mail]> <[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
>
>
>