Subject: [quicwg/base-drafts] Allow connections to share a port by adding restrictions on zero-length connection IDs (#2851)

From: David Schinazi <[email-masked]>
Date: Wed, 26 Jun 2019 14:25:39 -0700

In the current spec, zero-length connection IDs can be used when a host wants to route connections on the 4-tuple (remote IP/port, local IP/port). However, doing this prevents your peer from multiplexing connections on a single port. This PR restricts zero-length connection IDs to only be used when a host can route connection on the local 2-tuple (IP/port).

The current spec does not allow clients to share a local port ever, because at the time they start their connection they cannot know if a given server will want to route on the 4-tuple. Additionally, some clients might even be forced to perform this multiplexing because they are going through a proxy. Slightly restricting the use of zero-length connection IDs gives value to client connection IDs.

Fixes #2844.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/2851

-- Commit Summary --

  * Allow connections to share a port by adding restrictions on zero-length connection IDs

-- File Changes --

    M draft-ietf-quic-transport.md (41)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2851.patch
https://github.com/quicwg/base-drafts/pull/2851.diff

-- 
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/pull/2851

---

From: MikkelFJ <[email-masked]>
Date: Wed, 26 Jun 2019 14:30:41 -0700

mikkelfj commented on this pull request.

> @@ -924,11 +924,14 @@ selected by the client, both to ensure correct routing toward the client and to
 allow the client to validate that the packet is in response to an Initial
 packet.
 
-A zero-length connection ID MAY be used when the connection ID is not needed for
-routing and the address/port tuple of packets is sufficient to identify a
-connection. An endpoint whose peer has selected a zero-length connection ID MUST
-continue to use a zero-length connection ID for the lifetime of the connection
-and MUST NOT send packets from any other local address.
+A zero-length connection ID MAY be used when the connection ID is not needed
+for routing and the destination address and port of incoming packets is
+sufficient to identify a connection (e.g., when there is a single connection
+on a given local port). Note that it is not possible to use the source address
+and port of incoming packets to demultiplex them across connections because a
+peer might multiplex multiple connections on a single address and port and rely
+on its connection IDs for demultiplexing, and the peer's connection IDs are not
+transmitted in the short header packets they send.

because a peer or on path device might multiplex

-- 
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/pull/2851#pullrequestreview-254883672

---

From: MikkelFJ <[email-masked]>
Date: Wed, 26 Jun 2019 14:33:34 -0700

> The current spec does not allow clients to share a local port ever, because at the time they start their connection they cannot know if a given server will want to route on the 4-tuple. 

I'm not sure that is true, but if is, it should be fixed.

A P2P server scenario will definitely want to use a single port on both ends, and which one is client, might change at any given moment. In this case you have out of band knowledge about path behaviour.

For client p2p I'd hope that it is also possible to only use a single port when a CID is used.

-- 
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/pull/2851#issuecomment-506053693

---

From: David Schinazi <[email-masked]>
Date: Wed, 26 Jun 2019 15:15:24 -0700

@mikkelfj in the P2P case you often have a bootstrapping protocol (ICE, STUN, TURN, etc.) that gives you a single-use ephemeral port on both sides, so you can then happily use zero-length connection IDs because you'll only have one connection on that port. If you expect to share the port for multiple connections, then you can use non-zero-length CIDs, there's nothing in the spec (or this PR) that prevents that.

-- 
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/pull/2851#issuecomment-506064921

---

From: MikkelFJ <[email-masked]>
Date: Wed, 26 Jun 2019 23:23:45 -0700

On client P2P / ICE: These are yesterdays protocols. You can have a new version of these brokers. If you use IPV6 you could skipping the port step. Also a client implementation might skip the part of supporting multiple ports because you a skipping the OS and go with raw sockets, netmap, etc.. It is much simpler to just rely on the CID. Especially if you consider implementations that can also run outside of IP networks.

-- 
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/pull/2851#issuecomment-506209434

---

From: MikkelFJ <[email-masked]>
Date: Wed, 26 Jun 2019 23:25:25 -0700

On server P2P you do not have a boot strapping protocol. Then it is integral the service logic being implemented. I have a strong use case for this and would be very sad if ports cannot be stable.

-- 
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/pull/2851#issuecomment-506209912

---

From: David Schinazi <[email-masked]>
Date: Thu, 27 Jun 2019 09:17:47 -0700

@mikkelfj if your use-case uses non-zero-length connection IDs, then it is not relevant to this PR. This PR does not change how non-zero-length CIDs work.

-- 
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/pull/2851#issuecomment-506414159

---

From: MikkelFJ <[email-masked]>
Date: Thu, 27 Jun 2019 09:59:09 -0700

My objection was to the sentence "The current spec does not allow clients to share a local port ever"
which implies also with CID. Whether you PR fixes this or not is not clear to me, but I find it problematic if is correct and then not fixed.

-- 
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/pull/2851#issuecomment-506428826

---

From: David Schinazi <[email-masked]>
Date: Thu, 27 Jun 2019 10:17:55 -0700

Yes it is problematic, and this PR attempts to fix that.

-- 
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/pull/2851#issuecomment-506435059