Lines Matching +full:use +full:- +full:handshake
5 ---------
7 QUIC client-side connection state can be broken down into five coarse phases of
10 - The Idle substate (which is simply the state before we have started trying to
12 - The Active state, which comprises two substates:
13 - The Establishing state, which comprises many different substates;
14 - The Open state;
15 - The Terminating state, which comprises several substates;
16 - The Terminated state, which is the terminal state.
20 These names have been deliberately chosen to use different terminology to common
21 QUIC terms such as 'handshake' to avoid confusion, as they are not the same
22 concepts. For example, the Establishing state uses Initial, Handshake and 1-RTT
27 0-RTT is also not currently modelled in this analysis.
34 attention should not be given to the Open state, as 1-RTT application
36 the handshake has been completed but not yet confirmed).
44 - The Establishing state involves the use of Initial and Handshake
45 packets. It is terminated when the handshake is confirmed.
47 Handshake confirmation is not the same as handshake completion.
48 Handshake confirmation occurs on the client when it receives
49 a `HANDSHAKE_DONE` frame (which occurs in a 1-RTT packet, thus
50 1-RTT packets are also invoked in the Establishing state).
51 On the server, handshake confirmation occurs as soon as
52 the handshake is considered completed (see RFC 9001 s. 4.1).
56 - Proactive Version Negotiation (optional): The client sends
65 - Pre-Initial: The client has completed proactive version negotiation
71 - Initial Exchange A: The client has sent at least one Initial
76 - a Version Negotiation packet (leading to the Reactive Version
78 - a Retry packet (leading to Initial Exchange B); or
79 - an Initial packet (leading to the Initial Exchange Confirmed state).
81 - Reactive Version Negotiation: The server has rejected the client's
83 can be considered an error. Otherwise, we return to the Pre-Initial
87 - Initial Exchange B: The client has been asked to perform a Retry.
95 allowed to respond to a Retry-triggered Initial exchange with another
100 - a Version Negotiation packet (invalid, ignored);
101 - a Retry packet (invalid, ignored);
102 - an Initial packet (leading to the Initial Exchange Continued
105 - Initial Exchange Continued: The client has sent at least one
109 an arbitrarily long period until the handshake layer indicates the
110 Handshake EL is ready.
113 causes the handshake layer (whether it is TLS 1.3 or some other
114 hypothetical handshake layer) to emit keys for the Handshake EL.
117 handshake layer protocol messages to the handshake layer in use.
119 - Handshake: The Handshake EL is now available to the client.
120 Either client or server may send the first Handshake packet.
122 The client is waiting to receive a Handshake packet from the server.
124 - Handshake Continued: The client has received and successfully
125 decrypted at least one Handshake packet. The client now discards
126 the Initial EL. Communications via the handshake EL may continue for
129 The client is waiting to receive more Handshake packets from the
130 server to advance the handshake layer and cause it to transition
131 to the Handshake Completed state.
133 - Handshake Completed: The handshake layer has indicated that it
134 considers the handshake completed. For TLS 1.3, this means both
136 messages. The handshake layer must emit keys for the 1-RTT EL
139 Though the handshake is not yet confirmed, the client can begin
140 sending 1-RTT packets.
144 earlier in the handshake process, they are only considered
147 The client transitions to Handshake Confirmed once either
148 - it receives a `HANDSHAKE_DONE` frame in a 1-RTT packet, or
149 - it receives acknowledgement of any 1-RTT packet it sent.
152 noting that on the server, the handshake is considered confirmed as soon as
155 - Handshake Confirmed: The client has received confirmation from
156 the server that the handshake is confirmed.
158 The principal effect of moving to this state is that the Handshake
165 - The Open state is the steady state of the connection. It is a single state.
167 Application stream data is exchanged freely. Only 1-RTT packets are used. The
168 Initial, Handshake (and 0-RTT) ELs have been discarded, transport parameters
169 have been exchanged, and the handshake has been confirmed.
173 - the Terminating — Closing state if the local application initiates an
175 - the Terminating — Draining state if the remote peer initiates
177 - the Terminated state if the idle timeout expires; a `CONNECTION_CLOSE`
179 - the Terminated state if the peer triggers a stateless reset; a
182 - The Terminating state is used when closing the connection.
183 This may occur due to an application request or a transport-level
190 - The Closing state, used for a locally initiated immediate close. In
208 - The Draining state, used for a peer initiated immediate close.
217 - The Terminated state is the terminal state of a connection.
218 Regardless of how a connection ends (local or peer-initiated immediate close,
338 <td>—<tt>TLS:HAVE_EL(HANDSHAKE)</tt>→</td>
339 <td><tt>ACTIVE.ESTABLISHING.HANDSHAKE</tt></td>
342 <td rowspan="3"><tt>ACTIVE.ESTABLISHING.HANDSHAKE</tt></td>
343 <td rowspan="3"><tt>enter:ProvisionEL(Handshake)</tt><br/>
344 <tt>enter:SendPackets()</tt> (First Handshake packet, if pending)</td>
345 <td>—<tt>RX:HANDSHAKE</tt>→</td>
359 <td>—<tt>RX:HANDSHAKE</tt>→</td>
386 <td rowspan="1"><tt>enter:DiscardEL(Handshake)</tt><br/><tt>enter:Permit1RTTKeyUpdate()</tt></td>
440 - `CAN_SEND` is raised when transmission of packets has been unblocked after previously
444 - Due to OS buffers or network-side write BIOs being full;
445 - Due to limits imposed by the chosen congestion controller.
456 - `PROBE_TIMEOUT` is raised after the PTO interval and stimulates generation
459 - `IDLE_TIMEOUT` is raised after the connection idle timeout expires.
465 - `RX:STATELESS_RESET` indicates receipt of a stateless reset, but note
469 - `RX:ANY[CONNECTION_CLOSE]` denotes a `CONNECTION_CLOSE` frame received
470 in any non-discarded EL.
472 - Any circumstance where `RX:RETRY` or `RX:VER_NEG` are not explicitly
475 - Protocol errors, etc. can be handled identically to `APP:CLOSE` events
481 - `SendPackets()` sends packets if we have anything pending for transmission,
485 Non-FSM Model
486 -------------
493 image).](./images/connection-state-machine.png)
498 - `APP:CONNECT`: Supported in `IDLE` state only.
500 - `RX:VER_NEG`: Handled in `ESTABLISHING.PROACTIVE_VER_NEG` and
503 - `RX:RETRY`: Handled in `ESTABLISHING.INITIAL_EXCHANGE_A` only.
505 - `PROBE_TIMEOUT`: Applicable to `OPEN` and all (non-ε) `ESTABLISHING`
510 - `IDLE_TIMEOUT`: Applicable to `OPEN` and all (non-ε) `ESTABLISHING` substates.
514 - `TERMINATING_TIMEOUT`: Timeout used by the `TERMINATING` state only.
516 - `CAN_SEND`: Applicable to `OPEN` and all (non-ε) `ESTABLISHING`
520 - `RX:STATELESS_RESET`: Applicable to all `ESTABLISHING` and `OPEN` states and
524 - `APP:CLOSE`: Supported in `IDLE`, `ESTABLISHING` and `OPEN` states.
525 (Reasonably a no-op in `TERMINATING` or `TERMINATED.`)
527 - `RX:ANY[CONNECTION_CLOSE]`: Supported in all `ESTABLISHING` and `OPEN` states,
530 - `RX:INITIAL`, `RX:HANDSHAKE`, `RX:1RTT`: Our willingness to process these is
534 Once we successfully decrypt a Handshake packet, we stop processing Initial
537 - `TLS:HAVE_EL(HANDSHAKE)`: Emitted by the handshake layer when Handshake EL
540 - `TLS:HANDSHAKE_COMPLETE`: Emitted by the handshake layer when the handshake
541 is complete. Implies connection has been authenticated. Also implies 1-RTT EL
542 keys are available. Whether the handshake is complete, and also whether it is
547 - `APP:CONNECT`: Need to know if application has invoked this event yet,
552 - `RX:VER_NEG`: Only valid if we have not yet received any successfully
555 - `RX:RETRY`: Only valid if we have sent an Initial packet to the server,
569 - `PROBE_TIMEOUT`: If we have sent at least one encrypted packet yet,
570 we can handle this via a standard probe-sending mechanism. Otherwise, we are
576 - `IDLE_TIMEOUT`: Only applicable in `ACTIVE` states.
581 - `TERMINATING_TIMEOUT`: Timer used in `TERMINATING` state only.
583 - `CAN_SEND`: Stimulates transmission of packets.
585 - `RX:STATELESS_RESET`: Always handled unless we are in `TERMINATED`.
587 - `APP:CLOSE`: Usually causes a transition to `TERMINATING.CLOSING`.
589 - `RX:INITIAL`, `RX:HANDSHAKE`, `RX:1RTT`: Willingness to process
593 - `TLS:HAVE_EL(HANDSHAKE)`: Handled by the handshake layer
596 - `TLS:HANDSHAKE_COMPLETE`: Should be noted as a flag and notification
601 - The `IDLE`, `ACTIVE`, `TERMINATING.CLOSED`, `TERMINATING.DRAINED` and
605 - The following flags are modelled:
606 - Retry Requested? (+ Original SCID, DCID if so)
607 - Have Sent Any Packet?
608 - Are we currently doing proactive version negotiation?
609 - Have Successfully Received Any Encrypted Packet?
610 - Handshake Completed?
611 - Handshake Confirmed?
613 - The following timers are modelled:
614 - PTO Timeout
615 - Terminating Timeout
616 - Idle Timeout
619 -------------------
621 - Phase 1: “Steady state only” model which jumps to the `ACTIVE.OPEN`
626 - Phase 2: “Dummy handshake” model which uses a one-byte protocol
627 as the handshake layer as a standin for TLS 1.3. e.g. a 0x01 byte “represents”
631 use this protocol and E2E testing will be performed against it. (This
635 - Phase 3: Final model with TLS 1.3 handshake layer fully plumbed in.