Subject: [quicwg/base-drafts] Connection migration does not keep consistent connection ID (#936)

From: MikkelFJ <[email-masked]>
Date: Thu, 16 Nov 2017 07:39:12 +0000 (UTC)

Section 3.6 in transport says that the connection ID survives connection migration.

Is this an old left-over or am I missing something?

Aside from the initial server CID change, the connection ID has a traceable history of changes via the NEW_CONNECTION_ID frame and the initial change would also be traceable with #714 in effect, but a single connection ID would currently be tied to a 5-tuple, making paragraph 3.6 somewhat confusing to me:

> 3.6. Connection Migration and Resilience to NAT Rebinding
> QUIC connections are identified by a Connection ID, a 64-bit unsigned number randomly generated by the server. QUIC’s consistent connection ID allows connections to survive changes to the client’s IP and port, such as those caused by NAT rebindings or by the client changing network connectivity to a new address. QUIC provides automatic cryptographic verification of a rebound lient, since the client continues to use the same session key for encrypting and decrypting packets. The consistent connection ID can be used to allow migration of the connection to a new server IP address as well, since the Connection ID remains consistent across changes in the client’s and the server’s network addresses.
> 

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

---

From: MikkelFJ <[email-masked]>
Date: Thu, 16 Nov 2017 07:42:51 +0000 (UTC)

Section 7.7 repeats some of the text in 3.6

-- 
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/936#issuecomment-344841169

---

From: Mike Bishop <[email-masked]>
Date: Thu, 16 Nov 2017 08:41:42 +0000 (UTC)

No, there are two different cases.  There's NAT rebinding, in which case the client's traffic suddenly starts arriving at the server from a new port (and possibly a new IP), and the Connection ID doesn't change because the client doesn't know it happened.  Then there's intentional migration by the client, in which it knowingly moves to a totally different network.  In that instance, the client can choose to change the Connection ID.

The server should be largely indifferent, in that it recognizes both Connection IDs as belonging to this session.

-- 
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/936#issuecomment-344853291

---

From: MikkelFJ <[email-masked]>
Date: Fri, 17 Nov 2017 09:10:48 +0000 (UTC)

Closed #936.

-- 
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/936#event-1346754069

---

From: MikkelFJ <[email-masked]>
Date: Fri, 17 Nov 2017 09:10:47 +0000 (UTC)

OK, I still find it a bit confusing but as long as the text refers to current state, that is fine with me.

-- 
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/936#issuecomment-345186644