Subject: [quicwg/base-drafts] Add a NEW_CONNECTION_ID frame (#491)

From: Martin Thomson <[email-masked]>
Date: Mon, 01 May 2017 21:56:39 -0700

This frame is used by servers to support client unlinkability across network
migrations.

This assumes that the client is aware of the need for unlinkability.  I haven't
gone into a lot of detail on rationale, why this might be needed and the like.
That stuff does need expansion, but we don't have a lot of agreement on the
finer details.  For the moment having the basic mechanism in place will allow
us to make progress.

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

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

-- Commit Summary --

  * Add a NEW_CONNECTION_ID frame

-- File Changes --

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

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/491.patch
https://github.com/quicwg/base-drafts/pull/491.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/491

---

From: janaiyengar <[email-masked]>
Date: Tue, 02 May 2017 18:32:30 -0700

janaiyengar approved this pull request.

one nit

> +between two points of network attachment.
+
+The NEW_CONNECTION_ID message includes a connection ID that the client can use
+for packets on the current connection.  This message also includes packet number
+gap, which is the number of packet numbers that the client skips when using the
+new connection ID.  Without this, the packet number field in the header might be
+used to link activity across networks.  A server MUST provide a 32-bit value for
+the packet number gap field that is indistinguishable from random to a passive
+observer.
+
+A client might need to send packets on multiple networks without receiving any
+response from the server.  To ensure that the client is not linkable across each
+of these changes, a new connection ID and packet number gap are needed for each
+network.  To support this, a server sends multiple NEW_CONNECTION_ID messages.
+Each NEW_CONNECTION_ID is marked with a sequence number, which determines the
+order in which they are used.

nit: "they are used." -> "they must be used."

> @@ -1854,6 +1902,49 @@ alive when a stream is open. The default is to send a PING frame after 15
 seconds of quiescence. A PING frame has no additional fields.

+## NEW_CONNECTION_ID Frame {#frame-new-connection-id}
+
+A server sends a NEW_CONNECTION_ID to provide the client with alternative
+connection IDs that can be used to break linkability when migrating connections
+(see {{migration-linkability}}).
+
+The NEW_CONNECTION_ID is as follows:
+
+~~~
+ 0                   1                   2                   3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|       Sequence (16)           |

8 bits ought to be enough - we aren't expecting > 255 migrations

... and this can wrap! I suppose you're trying to support a general scheme that supports up to 1 connection ID per packet. 16 bits would limit the BDP to 32K packets in this case (or 32MB, or a ~2Gbps x 100ms path), which is probably fine.

-- 
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/491#pullrequestreview-35926837

---

From: Marten Seemann <[email-masked]>
Date: Tue, 02 May 2017 18:45:29 -0700

Can we make this symmetric (write peer instead of server / client)?
In a p2p setting, it doesn't really make a difference which peer is which, and both of them might want to do a connection migration at some point. 

-- 
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/491#issuecomment-298806054

---

From: Martin Thomson <[email-masked]>
Date: Tue, 02 May 2017 19:07:49 -0700

@marten-seemann I would love to do that, but we'd want to change the underlying design so that the server sends one connection ID and the client sends another.  That's a valid design, but the current design assumes a single identifier that is selected by the server.

Can you open an issue so that we can track/discuss/reject that idea separately?  I don't think that we can just sneak this in here.

-- 
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/491#issuecomment-298808253

---

From: Martin Thomson <[email-masked]>
Date: Tue, 02 May 2017 19:09:48 -0700

martinthomson commented on this pull request.

Yes, this was part of the reasoning, the other was that at 255 it's much harder to get the wrapping right.  Of course, if we decided to do that we really would run out of packet numbers.  The fix, make the packet number much bigger, the 64-bit limit is pretty arbitrary anyway and the nonce for most AEADs is longer than that, meaning that we could go to as much as 96-bit without a redesign.

-- 
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/491#discussion_r114463218

---

From: ekr <[email-masked]>
Date: Tue, 02 May 2017 20:19:02 -0700

I think it's premature to land this; some of the obvious designs for changing conn-id frequently don't require attaching a PN gap. It's also worth noting that you don't need to explicitly carry that; you can generate it using an exported key and the new conn ID.

-- 
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/491#issuecomment-298814822

---

From: Martin Thomson <[email-masked]>
Date: Tue, 02 May 2017 20:43:37 -0700

Merged #491.

-- 
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/491#event-1066624530

---

From: Martin Thomson <[email-masked]>
Date: Tue, 02 May 2017 21:51:04 -0700

It might have been a little premature, but maybe you could phrase your concerns as deltas to the current design.  Removing the packet number field and replacing it with an exported value (is this a valid use for the context?) would be a valid enhancement.

-- 
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/491#issuecomment-298822801

---

From: ekr <[email-masked]>
Date: Wed, 03 May 2017 07:30:38 -0700

yes, I will do 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/491#issuecomment-298928076