Subject: [quicwg/base-drafts] Client port for new connections (#2061)

From: janaiyengar <[email-masked]>
Date: Tue, 27 Nov 2018 22:36:21 -0800

To minimize load on NATs, especially cone NATs, it might be a good idea to recommend using the same {IP + client port} on outgoing connections.  An added value is that it makes any 2/4-tuple based side-channels less leaky.

Clients should not use the same port when using a new IP, to avoid correlation when migrating connections.

On a related note, none of the drafts talk about use of UDP ports on the client side. The -http draft talks about use of ports on the server side, but there's no mention of client side ports.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2061

---

From: Marten Seemann <[email-masked]>
Date: Tue, 27 Nov 2018 22:50:40 -0800

This will also prevent you from using 0 byte connection IDs. 4 byte will be sufficient though, which might be good enough.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2061#issuecomment-442339120

---

From: Martin Thomson <[email-masked]>
Date: Wed, 28 Nov 2018 00:55:53 -0800

There are a whole bunch of trade-offs here that we need to be cognizant of.  Using the same port could be a proxy for "same device" even in the presence of NAT, which is a nice linkability signal, where the NAT would otherwise create some uncertainty about that.  For connections from the same host, same port indicates "same application".  Using the same port also means that you need to use connection IDs, which is less efficient.

We do already have advice about changing source port after a period (along with a new connection ID), which addresses the final point.  Combining that with advice on reusing ports complicates things a little because you need to observe quiescent period across multiple connections (maybe, I don't know how this might look).

All in, I think that it's probably best to let a system of best practices evolve around this rather than stipulate any specific behaviour.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2061#issuecomment-442369044

---

From: mirjak <[email-masked]>
Date: Wed, 28 Nov 2018 02:07:56 -0800

We basically have an open issue in the ops-draft (26) to figure out if want to say more. In any case I think it would belong in the applicability statement.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2061#issuecomment-442391431

---

From: ianswett <[email-masked]>
Date: Wed, 28 Nov 2018 03:03:45 -0800

The one thing that may be worth adding text for is not adding linkability at the IP/port layer, but otherwise I'd rather wait for best practices to evolve as @martinthomson said.

Currently, the transport draft spends a lot of text and effort on ensuring connection IDs don't create linkability, but no text on ensuring the routing layer(ie: IP and port) don't do the exact same thing.  Possibly that belongs in security considerations?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2061#issuecomment-442408034

---

From: MikkelFJ <[email-masked]>
Date: Wed, 28 Nov 2018 03:52:53 -0800

Agree with MT/Ian.

On recommendation to not use same port when on a different IP, that probably makes sense in some common scenarios, but there are others where it would be a pain, especially when you do not use the Berkely socket interface for outbound UDP: In a docker cloud deployment you might hardcode the port in the application or environment and let the IP sort itself runtime. If for some reason the IP changes in the surrounding NAT layer, you don't want to deal with that. Nor do you generally want to deal with generating random ports.

So I think it might be a good recommendation for migratory client use cases, but it should not be a general requirement.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2061#issuecomment-442420732