Subject: Re: [quicwg/base-drafts] Multiple connections on the same port (#714)

From: Nick Banks <[email-masked]>
Date: Tue, 14 Nov 2017 15:27:00 +0000 (UTC)

Another possible solution:

Take 1 bit from each header's Type field and designate it the Client Connection ID flag (shown as `I` here). When set, it indicates the presence of the Client Connection ID field in the header.
```
 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
+-+-+-+-+-+-+-+-+
|1|I|  Type (6) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                       Connection ID (64)                      +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Packet Number (32)                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Version (32)                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                 [Client Connection ID (64)]                   +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Payload (*)                        ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
```
```
 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
+-+-+-+-+-+-+-+-+
|0|C|I|K|Type(4)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                     [Connection ID (64)]                      +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                 [Client Connection ID (64)]                   +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Packet Number (8/16/32)                ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Protected Payload (*)                   ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
```
Then, a server that changes the Connection ID is required include the Client Connection ID in all packets (long and short) it sends until it receives a packet from the client that uses the new Connection ID.

Also, I am not positive, but I believe these new flags and fields would have constant across versions.

If a client doesn't intent to share the port locally, then they should include the `omit_connection_id` transport parameter When set the server isn't required to send the Client Connection 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/issues/714#issuecomment-344294183

---

From: MikkelFJ <[email-masked]>
Date: Tue, 14 Nov 2017 15:32:36 +0000 (UTC)

@nibanks I have suggested something similar earlier, except I would make unconditional. The overhead  of always having the client ID in early long headers would be small and avoids affecting the crowded first byte. Connection migration also have to carry the old connection ID until peer uses the new 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/issues/714#issuecomment-344296029

---

From: Nick Banks <[email-masked]>
Date: Tue, 14 Nov 2017 15:37:13 +0000 (UTC)

I agree that for Long Headers it shouldn't be a big deal to have it unconditionally present, but it would need to be optional for Short Headers. And I do feel the Client Connection ID is needed for Short Headers in the 0-RTT scenario, in case the handshake packet in the Long Header is lost or reordered.

If it is optional in one header, I figured it would be good to keep the design uniform and make it optional in both.

-- 
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/714#issuecomment-344297544

---

From: MikkelFJ <[email-masked]>
Date: Tue, 14 Nov 2017 15:40:34 +0000 (UTC)

I'm not up to speed on 0-RTT, but it seems that in this case a long header could be used until the connection settles on a single 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/issues/714#issuecomment-344298696

---

From: Nick Banks <[email-masked]>
Date: Tue, 14 Nov 2017 15:45:10 +0000 (UTC)

The server replies to 0-RTT packets (Long Header) with 1-RTT packets (Short Header). If we require the client to acknowledge the new Connection ID before the server sends Short Header packets, then we effectively lose the 0-RTT feature if/when the server changes Connection 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/issues/714#issuecomment-344300266

---

From: MikkelFJ <[email-masked]>
Date: Tue, 14 Nov 2017 16:07:23 +0000 (UTC)

@nibanks Right.

Another concern is AEAD encryption based on the connection ID. If the client ID is encrypted, the client cannot use the ID to map the new server. However, if the server continues to reply with client connection ID and carries the new server ID in the packet, or perhaps in some TLS parameter as suggestion by @ianswett, then the client can easily make the link between the connections and connection ID based client to server routing would still work since the client changes ID. Still not sure about the 0-RTT impact.

-- 
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/714#issuecomment-344307767

---

From: Nick Banks <[email-masked]>
Date: Tue, 14 Nov 2017 16:21:06 +0000 (UTC)

@mikkelfj I'm unsure what you mean in your comment above. The client that receives the packet needs to know the previous Connection ID before it can decrypt it. That means it must be unencrypted.

I don't think we should rely on a model where the client is just expected to figure it out by trying to decrypt the packet for all outstanding Connections. I'm not sure how you would ever support encryption offload efficiently in a model like that.

As far as using a TLS parameter, that goes back to the problem of needing the previous Connection ID before decryption. Since all TLS data is inside the encryption, that won't 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/issues/714#issuecomment-344312206

---

From: MikkelFJ <[email-masked]>
Date: Tue, 14 Nov 2017 16:29:03 +0000 (UTC)

@nibanks clear text packets are encrypted and tagged with the connection ID (cleat text AEAD). Thus you need the connection ID to decrypt and verify. But it was a brain fart because regardless of which connection ID is being used to derive a key for cleartext AEAD, the connection ID is avaiable in the packet as clear text at a fixed location.

With TLS, it could work if the server uses the client connection ID in responses and stores the new connection ID in TLS, whereas the opposite would not work. Or did I miss something?

-- 
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/714#issuecomment-344314905

---

From: Nick Banks <[email-masked]>
Date: Tue, 14 Nov 2017 16:36:42 +0000 (UTC)

Maybe we are crossing paths and misunderstanding each other. Here is the problem I am trying to solve:

1. A client has N new Connections (in the handshake state) to the same remote IP/Port on the same local IP/Port.
2. The client receives a packet (long header or short header) on that local IP/Port with a Connection ID it doesn't know about.

How can the client determine which Connection to deliver that packet to for processing?

Since the packet is encrypted with the Client Connection ID and not the Server Connection ID, it cannot decrypt the packet until it has determined what the Client Connection ID was. Therefore, it cannot rely on any encrypted information to calculate the Client Connection 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/issues/714#issuecomment-344317467

---

From: MikkelFJ <[email-masked]>
Date: Tue, 14 Nov 2017 19:10:04 +0000 (UTC)

@nibanks I think we see and intend the same thing, largely.

Speaking only of clear text packets with no TLS magic: a clear text packet is encrypted with a key derived from  the connection ID listed in the same packets header. It does not matter what type of connection ID it is because the key can be derived regardless. There is no need to make a connection assocation with internal context before decryption. Once decrypted the new proposed client-ID can be retrieved and the necessary association created. (Becauase encryption contexts may be cashed, it may matter for efficiency whether client-ID or server-ID is being used, but it does not for being able to decrypt or assocaite contexts, assuming the extra proposed ID field).

As to carrying the missing ID in TLS: (I'm not fully up to speed here), but it would be necessary to have the client ID visible such that the client can efficiently associate server packets with client context and retrieve content, but I'll skip the details. I believe Ians proposal was to keep using the client ID until a server ID update was received and for all practical purposes start a new connection with that ID, which might add som roundtrip overhead, though I'm not sure.

-- 
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/714#issuecomment-344364816

---

From: Nick Banks <[email-masked]>
Date: Tue, 14 Nov 2017 19:23:28 +0000 (UTC)

@mikkelfj This statement is incorrect:
> a clear text packet is encrypted with a key derived from the connection ID listed in the same packets header.

Handshake packets are encrypted with the client's connection ID, which the server doesn't include in the packet currently. See this quote from the TLS section 5.2.1:
> Packets that carry the TLS handshake (Initial, Retry, and Handshake) are protected with secrets derived from the connection ID used in the client’s Initial packet.

-- 
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/714#issuecomment-344368716

---

From: MikkelFJ <[email-masked]>
Date: Tue, 14 Nov 2017 19:47:29 +0000 (UTC)

@nibanks ahh I see. Then some tweaking is needed such as keeping the client ID in return path and optionally list a new server ID as an optional packet field. Isn't this then largely Ians proposal in #713?

-- 
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/714#issuecomment-344375893

---

From: ianswett <[email-masked]>
Date: Tue, 14 Nov 2017 21:10:29 +0000 (UTC)

I think we should try: 'Put a new connection ID in a TLS extension or QUIC transport params' and then always have the client be the one to change the routing connection ID first and the server replies once it sees it.  I think that works both for stateless reset and for changing connection ID on the SHLO, and it seems a lot more explicit than just allowing the server to change the connection ID at certain points in the handshake without knowing what the new one will be.

@mikkelfj Yes, that's what I was hoping to use to close #713 as well.

-- 
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/714#issuecomment-344399555

---

From: Nick Banks <[email-masked]>
Date: Tue, 14 Nov 2017 21:36:30 +0000 (UTC)

@ianswett That sounds like an acceptable solution to 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/714#issuecomment-344406952

---

From: MikkelFJ <[email-masked]>
Date: Wed, 15 Nov 2017 08:36:00 +0000 (UTC)

Just be curios, not attempting to shoot anything down, but some things to consider:

- How does Ian's proposal deal with connection migration?
- And is there any issues with 0-RTT and ekstra roundtrips?
- How does client update to server CID work with short packet headers when CID is not present in the header (normally multiple connections per source port would have a CID present, but still).

Presumably a new server CID is to move connection routing to a new server endpoint and 0-RTT ought to already hit the desired endpoint in first go, or it isn't 0-RTT, so is server changed CID a thing for 0-RTT?

-- 
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/714#issuecomment-344522152

---

From: ianswett <[email-masked]>
Date: Wed, 15 Nov 2017 08:43:17 +0000 (UTC)

My proposal is only aimed at the handshake, so I don't think it should effect connection migration.

This shouldn't cost any extra round trips, since the TLS messages already include transport params and/or extensions.

For short headers, we're talking post-handshake, in which case I think the NEW_CONNECTION_ID frame is the right way to go.

-- 
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/714#issuecomment-344523912

---

From: MikkelFJ <[email-masked]>
Date: Wed, 15 Nov 2017 09:04:27 +0000 (UTC)

makes sense

-- 
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/714#issuecomment-344529013