Subject: Server-chosen connection ID, final cleartext packet, and load balancers

From: Kyle Rose <[email-masked]>
Date: Thu, 30 Mar 2017 11:18:15 -0500

I interpreted the discussion about connection ID early in the session as
"everything prior to the final cleartext packet requires no load balancer
state", and asked for clarification on the jabber channel. Ben Kaduk
replied:

q( I was hearing that, if you have a load-balancer setup, it has to be
able to deal with zero or "random" connection IDs, because they will
be used for the initial cleartext packets.  Therefore, there's no
reason to try and do something fancy once the server does have a
chance to select something, so the server should just pick the
client's initial value in most cases, and the load balancer would be
based on some sort of persistent hashing-like thing. )

Is this right? ISTM the point of a server-chosen connection ID is to permit
interesting (i.e., not consistent hash-based) load balancing by the server
without out-of-band state sharing. In the general case, this means the
server-provided connection ID being used on every single packet once more
than a trivial amount of state (whatever fits in 64 bits) needs to be known
to whatever the eventual LB-chosen server is.

Encryption keys cannot be encoded in 64 bits. Is the intent of "final
cleartext packet" combined with "TLS handshake always in the clear" that
the server-chosen connection ID is not employed until the TLS handshake has
completed? If so, it seems we've already decided that global state sharing
is required. Alternatively, we could allow for 1-RTT with a consistent
hash-chosen server to be followed immediately by a (possibly optimized)
0-RTT reconnect to an LB-chosen server with a session ticket. Or, we could
split off connection ID and load balancer cookie and set the latter much
earlier.

Mostly I would like clarification on the actual status quo before trying to
explore the design space.

Kyle

---

From: "Lubashev, Igor" <[email-masked]>
Date: Thu, 30 Mar 2017 20:54:29 +0000

Server-contributed Connection ID is there to allow load balancers locate the backend server w/o keeping a distributed connection table.  This is especially important in the case of connection migration or long-lived connections.

There is no magic associated with “last server cleartext”, except it is a well-defined point: client-generated connection ID if (Short-Header or Type=2|5); server-generated otherwise.  [Small problem – Public Reset can have either connection ID!].

There is another proposal by Subodh to allow the server to choose its connection ID at any time.  In that proposal, client always starts with connection ID=0 and server is free to choose its connection ID at any time, and the client then always uses that. This makes it even easier to identify server’s connection ID (0 or non-0).

-          Igor

From: Kyle Rose [mailto:[email-masked]]
Sent: Thursday, March 30, 2017 11:18 AM
To: IETF QUIC WG <[email-masked]>
Cc: Lubashev, Igor <[email-masked]>; Benjamin Kaduk <[email-masked]>
Subject: Server-chosen connection ID, final cleartext packet, and load balancers

I interpreted the discussion about connection ID early in the session as "everything prior to the final cleartext packet requires no load balancer state", and asked for clarification on the jabber channel. Ben Kaduk replied:
q( I was hearing that, if you have a load-balancer setup, it has to be
able to deal with zero or "random" connection IDs, because they will
be used for the initial cleartext packets.  Therefore, there's no
reason to try and do something fancy once the server does have a
chance to select something, so the server should just pick the
client's initial value in most cases, and the load balancer would be
based on some sort of persistent hashing-like thing. )
Is this right? ISTM the point of a server-chosen connection ID is to permit interesting (i.e., not consistent hash-based) load balancing by the server without out-of-band state sharing. In the general case, this means the server-provided connection ID being used on every single packet once more than a trivial amount of state (whatever fits in 64 bits) needs to be known to whatever the eventual LB-chosen server is.
Encryption keys cannot be encoded in 64 bits. Is the intent of "final cleartext packet" combined with "TLS handshake always in the clear" that the server-chosen connection ID is not employed until the TLS handshake has completed? If so, it seems we've already decided that global state sharing is required. Alternatively, we could allow for 1-RTT with a consistent hash-chosen server to be followed immediately by a (possibly optimized) 0-RTT reconnect to an LB-chosen server with a session ticket. Or, we could split off connection ID and load balancer cookie and set the latter much earlier.
Mostly I would like clarification on the actual status quo before trying to explore the design space.

Kyle

---

From: "Lubashev, Igor" <[email-masked]>
Date: Thu, 30 Mar 2017 21:07:00 +0000

Ø  There is no magic associated with “last server cleartext”, except it is a well-defined point: client-generated connection ID if (Short-Header or Type=2|5); server-generated otherwise.  [Small problem – Public Reset can have either connection ID!].

Sorry, got this wrong.  *blush*

Client-generated connection ID if (Long-Header AND Type=2|5),
Server-generated connection ID otherwise, except
No Idea, if (Long-Header AND Type=8).

From: Lubashev, Igor [mailto:[email-masked]]
Sent: Thursday, March 30, 2017 3:54 PM
To: Kyle Rose <[email-masked]>; IETF QUIC WG <[email-masked]>
Cc: Benjamin Kaduk <[email-masked]>
Subject: RE: Server-chosen connection ID, final cleartext packet, and load balancers

-          Igor

From: Kyle Rose [mailto:[email-masked]]
Sent: Thursday, March 30, 2017 11:18 AM
To: IETF QUIC WG <[email-masked]<mailto:[email-masked]>>
Cc: Lubashev, Igor <[email-masked]<mailto:[email-masked]>>; Benjamin Kaduk <[email-masked]<mailto:[email-masked]>>
Subject: Server-chosen connection ID, final cleartext packet, and load balancers

Kyle