Subject: [quicwg/base-drafts] Move connection ID change to only Server Cleartext (#589)

From: Martin Thomson <[email-masked]>
Date: Tue, 06 Jun 2017 02:57:48 -0700

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

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

-- Commit Summary --

  * Move connection ID change to only Server Cleartext

-- File Changes --

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

-- Patch Links --

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

---

From: Mike Bishop <[email-masked]>
Date: Tue, 06 Jun 2017 04:57:14 -0700

MikeBishop commented on this pull request.

> @@ -595,11 +592,9 @@ It carries cryptographic handshake messages and acknowledgments.  It is used
 by a server that wishes to perform a stateless retry (see
 {{stateless-retry}}).
 
-The connection ID field in a Server Stateless Retry packet contains a server
-selected value, see {{connection-id}}.
-
-The packet number field echoes the packet number of the triggering client
-packet.  This allows a client to verify that the server received its packet.
+The packet number and connection ID fields echo the packet number of the

This says the connection ID field contain's the original packet's packet number.  Don't think that's correct.

-- 
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/589#pullrequestreview-42286624

---

From: Lars Eggert <[email-masked]>
Date: Tue, 06 Jun 2017 04:57:36 -0700

larseggert approved this pull request.

-- 
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/589#pullrequestreview-42286689

---

From: Martin Thomson <[email-masked]>
Date: Tue, 06 Jun 2017 05:01:02 -0700

martinthomson commented on this pull request.

I believe that it is correct. 

-- 
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/589#discussion_r120334529

---

From: Igor Lubashev <[email-masked]>
Date: Tue, 06 Jun 2017 05:01:56 -0700

So if I have 50% of the backend servers upgraded to a newer QUIC version, how do I make sure that client comes back to the same server after Version Negotiation?

-- 
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/589#issuecomment-306465149

---

From: Mike Bishop <[email-masked]>
Date: Tue, 06 Jun 2017 05:04:59 -0700

No, the packet number field should contain the client's packet number, and the connection ID field should contain the client's connection ID.  Otherwise, this is just... weird.

-- 
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/589#discussion_r120335268

---

From: Martin Thomson <[email-masked]>
Date: Tue, 06 Jun 2017 05:06:15 -0700

@martinthomson pushed 1 commit.

90b5b6e  Fix nits

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/589/files/56e55db3025a01186018a61bbc9ec73c4a6314f6..90b5b6eb1b1e142d054d449a7f8ba9b545432f04

---

From: Jānis <[email-masked]>
Date: Tue, 06 Jun 2017 05:19:11 -0700

Why such design changes? I want to selectively decide which server will load balance asymmetric cryptography (heavy processing) of TLS handshake. With this design its not possible.

-- 
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/589#issuecomment-306468807

---

From: Martin Thomson <[email-masked]>
Date: Tue, 06 Jun 2017 05:37:14 -0700

@chocis, That was discussed here at the interim as being a primary advantage of the current design.  No one spoke in favour of retaining 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/589#issuecomment-306473022

---

From: janaiyengar <[email-masked]>
Date: Tue, 06 Jun 2017 05:45:23 -0700

janaiyengar commented on this pull request.

> -the server, it uses the connection ID it received from the server.
-
-When the server receives a Client Initial packet, it chooses a new value for the
-connection ID and sends that in its response.  The server MUST send a new
-connection ID in any packet that is sent in response to a Client Initial packet.
-This includes Version Negotiation ({{packet-version}}), Server Stateless Retry
-({{packet-server-stateless}}), and the first Server Cleartext packet
-({{packet-server-cleartext}}).  The server MAY choose to use the value that the
-client initially selects.
-
-A server MUST NOT propose a different connection ID in response to a Client
-Cleartext packet ({{packet-client-cleartext}}).  A Client Cleartext packet is
-only sent after the server has committed to maintaining connection state.
+packets ({{packet-client-initial}}) and 0-RTT packets ({{packet-protected}}).
+If the client has received any packet from the server, it uses the connection ID
+it received from the server.

This sentence is slightly misleading, since 0-RTT packets will continue using the client Connection ID. I would remove this sentence since paras below cover everything else.

-- 
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/589#pullrequestreview-42301745

---

From: Mike Bishop <[email-masked]>
Date: Tue, 06 Jun 2017 05:47:43 -0700

@huitema also spoke *against* that, since it becomes easy for an attacker to forge.

-- 
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/589#issuecomment-306475427

---

From: Martin Thomson <[email-masked]>
Date: Tue, 06 Jun 2017 05:54:32 -0700

-

"... for all packets other than 0-RTT packets." ?

-- 
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/589#discussion_r120349743

---

From: Martin Thomson <[email-masked]>
Date: Tue, 06 Jun 2017 05:55:08 -0700

b8c42b4  Client doesn't use SCID for 0-RTT.

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/589/files/90b5b6eb1b1e142d054d449a7f8ba9b545432f04..b8c42b41d76034373e65cbaa44ac75346de6af13

---

From: janaiyengar <[email-masked]>
Date: Tue, 06 Jun 2017 06:43:48 -0700

janaiyengar approved this pull request.

-- 
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/589#pullrequestreview-42319008

---

From: janaiyengar <[email-masked]>
Date: Tue, 06 Jun 2017 06:45:08 -0700

Merged #589.

-- 
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/589#event-1111796493

---

From: Jānis <[email-masked]>
Date: Tue, 06 Jun 2017 08:10:13 -0700

Well then I would like to propose to reconsider that. Is there any reason why Server Stateless Retry couldn't change CID?

1) Firstly, in my opininon server without using Server Stateless Retry (without verifying src address/port) is simply asking to be DOS attacked. I could fill server's RAM with Raspberry Pi by simply spoofing src address. Thats why I am talking about situation where that check is enabled.

2) Secondly, imageine that you want to use CID for load balancing your clients. In current solution you would have to support accepting TLS handshake on all backends and when initial request is validated the partial TLS and QUIC state must be serialized and somehow transported to decided loadbalanced server (with the new CID) - and thats not easy AT ALL. I think, that this can be solved by simply returning new CID in Server Stateless Retry without doing any work or state transportation on backend.

-- 
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/589#issuecomment-306517012

---

From: Igor Lubashev <[email-masked]>
Date: Tue, 06 Jun 2017 13:54:34 -0700

The way I would implement the load balancer:

1. If the packet has CCID, consistent hash it into the pool of backend servers for this dest IP or hostname based on the 6-tuple (5+tuple + CCID) and forward the packet.
1a. The backend server replies with a Version Negotiation packet (too bad cannot use SCID here). or
1b. The backend server replies with a SCID to continue the handshake.

2. If the packet has SCID, validate that SCID seems ok and forward the packet to the identified server.

-- 
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/589#issuecomment-306614086