Closed frochet closed 3 years ago
The Connection ID is derived from the sequence number of the token used, as explained in the last paragraph. Thus, this race does not exists. Is the text unclear in that regard?
Ah right. Then how do we specify Connection ID if several TCP connections are performed before the TLS handshake?
I believe this example fits your question: A client has received two tokens ([1, abc],[2,def]) over a main connection A, it opens two TCP connections. The first one (B) uses the token "abc", the second (C) uses the token "def". Whenever the TLS handshake completes on connection B or C, the sequence number is retrieved from the token value. For C, its connection ID becomes 2, while it becomes 1 for A. So to wrap up, connection IDs are determined in advance by the server when providing the tokens.
The problem I am referring is when you don't have a main connection A.
You fire TCP A & B, and then handshake over A or B and Join over the other. In that case the Connection ID that is supposed to identify a TCP connection does not actually identify the TCP connection before the TLS handshake and Join handshake terminate.
Maybe it is a terminology problem. It should identify a TCP connection when its TCPLS handshake state is either Finished or Joined?
Tokens are provided after the handshake fo the main connection A, so I don't get the issue. Connection ID is used to identify a connection part of TCPLS session. if it's not part of a session, it does not have an CID. If it's the first one of a session, it has CID 0. If it's a subsequent connection, it uses the sequence number of the token used when joining as the CID.
A kind of protocol data race may happen if, say, the client fires two TCP connections at the same time but the order of establishment is not the same for the client and the server.
In this situation one may have the Connection ID swapped for both peer.
One solution could be a sanity check after concurrent connection establishments.