1QUIC Connection State Machine 2============================= 3 4FSM Model 5--------- 6 7QUIC client-side connection state can be broken down into five coarse phases of 8a QUIC connection: 9 10- The Idle substate (which is simply the state before we have started trying to 11 establish a connection); 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. 17 18There is monotonic progression through these phases. 19 20These names have been deliberately chosen to use different terminology to common 21QUIC terms such as 'handshake' to avoid confusion, as they are not the same 22concepts. For example, the Establishing state uses Initial, Handshake and 1-RTT 23packets. 24 25This discussion is (currently) given from the client side perspective only. 26State machine considerations only relevant to servers are not mentioned. 270-RTT is also not currently modelled in this analysis. 28 29The synthesis of this FSM is not suggested by the QUIC RFCs but has been 30discerned from the requirements imposed. This does not mean that the 31implementation of this FSM as literally presented below is an optimal or 32advisable implementation strategy, and a cursory examination of existing QUIC 33implementations suggests that such an approach is not common. Moreover, excess 34attention should not be given to the Open state, as 1-RTT application 35communication can occur even still in the Establishing state (for example, when 36the handshake has been completed but not yet confirmed). 37 38However, the state machine described herein is helpful as an aid to 39understanding and broadly captures the logic which our implementation will 40embody. The design of the actual implementation is discussed further below. 41 42The above states and their substates are defined as follows: 43 44- The Establishing state involves the use of Initial and Handshake 45 packets. It is terminated when the handshake is confirmed. 46 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). 53 54 The Establishing state is subdivided into the following substates: 55 56 - Proactive Version Negotiation (optional): The client sends 57 a Version Negotiation packet with a reserved version number 58 to forcibly elicit a list of the server's supported versions. 59 This is not expected to be commonly used, as it adds a round trip. 60 61 If it is used, the time spent in this state is based on waiting for 62 the server to respond, and potentially retransmitting after a 63 timeout. 64 65 - Pre-Initial: The client has completed proactive version negotiation 66 (if it performed it), but has not yet sent any encrypted packet. This 67 substate is included for exposition; no time will generally be spent in it 68 and there is immediate transmission of the first encrypted packet and 69 transition to Initial Exchange A. 70 71 - Initial Exchange A: The client has sent at least one Initial 72 packet to the server attempting to initiate a connection. 73 74 The client is waiting for a server response, which might 75 be: 76 - a Version Negotiation packet (leading to the Reactive Version 77 Negotiation state); 78 - a Retry packet (leading to Initial Exchange B); or 79 - an Initial packet (leading to the Initial Exchange Confirmed state). 80 81 - Reactive Version Negotiation: The server has rejected the client's 82 proposed version. If proactive version negotiation was used, this 83 can be considered an error. Otherwise, we return to the Pre-Initial 84 state and proceed as though proactive version negotiation was 85 performed using the information in the version negotiation packet. 86 87 - Initial Exchange B: The client has been asked to perform a Retry. 88 It sends at least one Initial packet to the server attempting to 89 initiate a connection. Every Initial packet contains the quoted Retry 90 Token. Any data sent in `CRYPTO` frames in Initial Exchange A must be 91 retransmitted, but PNs MUST NOT be reset. Note that this is still 92 considered part of the same connection, and QUIC Transport Parameters are 93 later used to cryptographically bind the established connection state to 94 the original DCIDs used as part of the Retry process. A server is not 95 allowed to respond to a Retry-triggered Initial exchange with another 96 Retry, and if it does we ignore it, which is the major distinction of this 97 state from Initial Exchange A. 98 99 The client is waiting for a server response, which might be: 100 - a Version Negotiation packet (invalid, ignored); 101 - a Retry packet (invalid, ignored); 102 - an Initial packet (leading to the Initial Exchange Continued 103 state); 104 105 - Initial Exchange Continued: The client has sent at least one 106 Initial packet to the server and received at least one valid Initial packet 107 from the server. There is no longer any possibility of a Retry (any such 108 packet is ignored) and communications may continue via Initial packets for 109 an arbitrarily long period until the handshake layer indicates the 110 Handshake EL is ready. 111 112 The client is waiting for server packets, until one of those packets 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. 115 This will generally occur due to incoming Initial packets containing 116 crypto stream segments (in the form of `CRYPTO` frames) which deliver 117 handshake layer protocol messages to the handshake layer in use. 118 119 - Handshake: The Handshake EL is now available to the client. 120 Either client or server may send the first Handshake packet. 121 122 The client is waiting to receive a Handshake packet from the server. 123 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 127 an arbitrary period of time. 128 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. 132 133 - Handshake Completed: The handshake layer has indicated that it 134 considers the handshake completed. For TLS 1.3, this means both 135 parties have sent and received (and verified) TLS 1.3 Finished 136 messages. The handshake layer must emit keys for the 1-RTT EL 137 at this time. 138 139 Though the handshake is not yet confirmed, the client can begin 140 sending 1-RTT packets. 141 142 The QUIC Transport Parameters sent by the peer are now authenticated. 143 (Though the peer's QUIC Transport Parameters may have been received 144 earlier in the handshake process, they are only considered 145 authenticated at this point.) 146 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. 150 151 Though this discussion only covers the client state machine, it is worth 152 noting that on the server, the handshake is considered confirmed as soon as 153 it is considered completed. 154 155 - Handshake Confirmed: The client has received confirmation from 156 the server that the handshake is confirmed. 157 158 The principal effect of moving to this state is that the Handshake 159 EL is discarded. Key Update is also now permitted for the first 160 time. 161 162 The Establishing state is now done and there is immediate transition 163 to the Open state. 164 165- The Open state is the steady state of the connection. It is a single state. 166 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. 170 171 The client transitions to 172 173 - the Terminating — Closing state if the local application initiates an 174 immediate close (a `CONNECTION_CLOSE` frame is sent); 175 - the Terminating — Draining state if the remote peer initiates 176 an immediate close (i.e., a `CONNECTION_CLOSE` frame is received); 177 - the Terminated state if the idle timeout expires; a `CONNECTION_CLOSE` 178 frame is NOT sent; 179 - the Terminated state if the peer triggers a stateless reset; a 180 `CONNECTION_CLOSE` frame is NOT sent. 181 182- The Terminating state is used when closing the connection. 183 This may occur due to an application request or a transport-level 184 protocol error. 185 186 Key updates may not be initiated in the Terminating state. 187 188 This state is divided into two substates: 189 190 - The Closing state, used for a locally initiated immediate close. In 191 this state, a packet containing a `CONNECTION_CLOSE` frame is 192 transmitted again in response to any packets received. This ensures 193 that a `CONNECTION_CLOSE` frame is received by the peer even if the 194 initially transmitted `CONNECTION_CLOSE` frame was lost. Note that 195 these `CONNECTION_CLOSE` frames are not governed by QUIC's normal loss 196 detection mechanisms; this is a bespoke mechanism unique to this 197 state, which exists solely to ensure delivery of the `CONNECTION_CLOSE` 198 frame. 199 200 The endpoint progresses to the Terminated state after a timeout 201 interval, which should not be less than three times the PTO interval. 202 203 It is also possible for the endpoint to transition to the Draining 204 state instead, if it receives a `CONNECTION_CLOSE` frame prior 205 to the timeout expiring. This indicates that the peer is also 206 closing. 207 208 - The Draining state, used for a peer initiated immediate close. 209 210 The local endpoint may not send any packets of any kind in this 211 state. It may optionally send one `CONNECTION_CLOSE` frame immediately 212 prior to entering this state. 213 214 The endpoint progresses to the Terminated state after a timeout 215 interval, which should not be less than three times the PTO interval. 216 217- The Terminated state is the terminal state of a connection. 218 Regardless of how a connection ends (local or peer-initiated immediate close, 219 idle timeout, stateless reset), a connection always ultimately ends up in this 220 state. There is no longer any requirement to send or receive any packet. No 221 timer events related to the connection will ever need fire again. This is a 222 totally quiescent state. The state associated with the connection may now be 223 safely freed. 224 225We express this state machine in more concrete form in the form of a table, 226which makes the available transitions clear: 227 228† Except where superseded by a more specific transition 229 230ε means “where no other transition is applicable”. 231 232Where an action is specified in the Transition/Action column but no new state, 233no state change occurs. 234 235<table> 236<tr><th>State</th><th>Action On Entry/Exit</th><th>Event</th><th>Transition/Action</th></tr> 237<tr> 238 <td rowspan="2"><tt>IDLE</tt></td> 239 <td rowspan="2"></td> 240 <td>—<tt>APP:CONNECT</tt>→</td> 241 <td><tt>ACTIVE.ESTABLISHING.PROACTIVE_VER_NEG</tt> (if used), else 242 <tt>ACTIVE.ESTABLISHING.PRE_INITIAL</tt></td> 243</tr> 244<tr> 245 <td>—<tt>APP:CLOSE</tt>→</td> 246 <td><tt>TERMINATED</tt></td> 247</tr> 248<tr> 249 <td rowspan="5"><tt>ACTIVE</tt></td> 250 <td rowspan="5"></td> 251 <td>—<tt>IDLE_TIMEOUT</tt>→</td> 252 <td><tt>TERMINATED</tt></td> 253</tr> 254<tr> 255 <td>—<tt>PROBE_TIMEOUT</tt>→ †</td> 256 <td><tt>SendProbeIfAnySentPktsUnacked()</tt></td> 257</tr> 258<tr> 259 <td>—<tt>APP:CLOSE</tt>→ †</td> 260 <td><tt>TERMINATING.CLOSING</tt></td> 261</tr> 262<tr> 263 <td>—<tt>RX:ANY[CONNECTION_CLOSE]</tt>→</td> 264 <td><tt>TERMINATING.DRAINING</tt></td> 265</tr> 266<tr> 267 <td>—<tt>RX:STATELESS_RESET</tt>→</td> 268 <td><tt>TERMINATED</tt></td> 269</tr> 270 271<tr> 272 <td rowspan="3"><tt>ACTIVE.ESTABLISHING.PROACTIVE_VER_NEG</tt></td> 273 <td rowspan="3"><tt>enter:SendReqVerNeg</tt></td> 274 <td>—<tt>RX:VER_NEG</tt>→</td> 275 <td><tt>ACTIVE.ESTABLISHING.PRE_INITIAL</tt></td> 276</tr> 277<tr> 278 <td>—<tt>PROBE_TIMEOUT</tt>→</td> 279 <td><tt>ACTIVE.ESTABLISHING.PROACTIVE_VER_NEG</tt> (retransmit)</td> 280</tr> 281<tr> 282 <td>—<tt>APP:CLOSE</tt>→</td> 283 <td><tt>TERMINATED</tt></td> 284</tr> 285<tr> 286 <td rowspan="1"><tt>ACTIVE.ESTABLISHING.PRE_INITIAL</tt></td> 287 <td rowspan="1"></td> 288 <td>—ε→</td> 289 <td><tt>ACTIVE.ESTABLISHING.INITIAL_EXCHANGE_A</tt></td> 290</tr> 291<tr> 292 <td rowspan="4"><tt>ACTIVE.ESTABLISHING.INITIAL_EXCHANGE_A</tt></td> 293 <td rowspan="4"><tt>enter:SendPackets()</tt> (First Initial)</td> 294 <td>—<tt>RX:RETRY</tt>→</td> 295 <td><tt>ACTIVE.ESTABLISHING.INITIAL_EXCHANGE_B</tt></td> 296</tr> 297<tr> 298 <td>—<tt>RX:INITIAL</tt>→</td> 299 <td><tt>ACTIVE.ESTABLISHING.INITIAL_EXCHANGE_CONTINUED</tt></td> 300</tr> 301<tr> 302 <td>—<tt>RX:VER_NEG</tt>→</td> 303 <td><tt>ACTIVE.ESTABLISHING.REACTIVE_VER_NEG</tt></td> 304</tr> 305<tr> 306 <td>—<tt>CAN_SEND</tt>→</td> 307 <td><tt>SendPackets()</tt></td> 308</tr> 309<tr> 310 <td rowspan="1"><tt>ACTIVE.ESTABLISHING.REACTIVE_VER_NEG</tt></td> 311 <td rowspan="1"></td> 312 <td>—ε→</td> 313 <td><tt>ACTIVE.ESTABLISHING.PRE_INITIAL</tt></td> 314</tr> 315<tr> 316 <td rowspan="3"><tt>ACTIVE.ESTABLISHING.INITIAL_EXCHANGE_B</tt></td> 317 <td rowspan="3"><tt>enter:SendPackets()</tt><br/> 318 (First Initial, with token)<br/> 319 (*All further Initial packets contain the token)<br/>(*PN is not reset)</td> 320 <td>—<tt>RX:INITIAL</tt>→</td> 321 <td><tt>ACTIVE.ESTABLISHING.INITIAL_EXCHANGE_CONTINUED</tt></td> 322</tr> 323<tr> 324 <td>—<tt>PROBE_TIMEOUT</tt>→</td> 325 <td>TODO: Tail loss probe for initial packets?</td> 326</tr> 327<tr> 328 <td>—<tt>CAN_SEND</tt>→</td> 329 <td><tt>SendPackets()</tt></td> 330</tr> 331<tr> 332 <td rowspan="2"><tt>ACTIVE.ESTABLISHING.INITIAL_EXCHANGE_CONTINUED</tt></td> 333 <td rowspan="2"><tt>enter:SendPackets()</tt></td> 334 <td>—<tt>RX:INITIAL</tt>→</td> 335 <td>(packet processed, no change)</td> 336</tr> 337<tr> 338 <td>—<tt>TLS:HAVE_EL(HANDSHAKE)</tt>→</td> 339 <td><tt>ACTIVE.ESTABLISHING.HANDSHAKE</tt></td> 340</tr> 341<tr> 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> 346 <td><tt>ACTIVE.ESTABLISHING.HANDSHAKE_CONTINUED</tt></td> 347</tr> 348<tr> 349 <td>—<tt>RX:INITIAL</tt>→</td> 350 <td>(packet processed if EL is not dropped)</td> 351</tr> 352<tr> 353 <td>—<tt>CAN_SEND</tt>→</td> 354 <td><tt>SendPackets()</tt></td> 355</tr> 356<tr> 357 <td rowspan="3"><tt>ACTIVE.ESTABLISHING.HANDSHAKE_CONTINUED</tt></td> 358 <td rowspan="3"><tt>enter:DropEL(Initial)</tt><br/><tt>enter:SendPackets()</tt></td> 359 <td>—<tt>RX:HANDSHAKE</tt>→</td> 360 <td>(packet processed, no change)</td> 361</tr> 362<tr> 363 <td>—<tt>TLS:HANDSHAKE_COMPLETE</tt>→</td> 364 <td><tt>ACTIVE.ESTABLISHING.HANDSHAKE_COMPLETE</tt></td> 365</tr> 366 <tr> 367 <td>—<tt>CAN_SEND</tt>→</td> 368 <td><tt>SendPackets()</tt></td> 369</tr> 370<tr> 371 <td rowspan="3"><tt>ACTIVE.ESTABLISHING.HANDSHAKE_COMPLETED</tt></td> 372 <td rowspan="3"><tt>enter:ProvisionEL(1RTT)</tt><br/><tt>enter:HandshakeComplete()</tt><br/><tt>enter[server]:Send(HANDSHAKE_DONE)</tt><br/><tt>enter:SendPackets()</tt></td> 373 <td>—<tt>RX:1RTT[HANDSHAKE_DONE]</tt>→</td> 374 <td><tt>ACTIVE.ESTABLISHING.HANDSHAKE_CONFIRMED</tt></td> 375</tr> 376<tr> 377 <td>—<tt>RX:1RTT</tt>→</td> 378 <td>(packet processed, no change)</td> 379</tr> 380 <tr> 381 <td>—<tt>CAN_SEND</tt>→</td> 382 <td><tt>SendPackets()</tt></td> 383</tr> 384<tr> 385 <td rowspan="1"><tt>ACTIVE.ESTABLISHING.HANDSHAKE_CONFIRMED</tt></td> 386 <td rowspan="1"><tt>enter:DiscardEL(Handshake)</tt><br/><tt>enter:Permit1RTTKeyUpdate()</tt></td> 387 <td>—ε→</td> 388 <td><tt>ACTIVE.OPEN</tt></td> 389</tr> 390<tr> 391 <td rowspan="2"><tt>ACTIVE.OPEN</tt></td> 392 <td rowspan="2"></td> 393 <td>—<tt>RX:1RTT</tt>→</td> 394 <td>(packet processed, no change)</td> 395</tr> 396<tr> 397 <td>—<tt>CAN_SEND</tt>→</td> 398 <td><tt>SendPackets()</tt></td> 399</tr> 400<tr> 401 <td rowspan="2"><tt>TERMINATING</tt></td> 402 <td rowspan="2"></td> 403 <td>—<tt>TERMINATING_TIMEOUT</tt>→</td> 404 <td><tt>TERMINATED</tt></td> 405</tr> 406<tr> 407 <td>—<tt>RX:STATELESS_RESET</tt>→</td> 408 <td><tt>TERMINATED</tt></td> 409</tr> 410<tr> 411 <td rowspan="3"><tt>TERMINATING.CLOSING</tt></td> 412 <td rowspan="3"><tt>enter:QueueConnectionCloseFrame()</tt><br/><tt>enter:SendPackets()</tt></td> 413 <td>—<tt>RX:ANY[CONNECTION_CLOSE]</tt>→</td> 414 <td><tt>TERMINATING.DRAINING</tt></td> 415</tr> 416<tr> 417 <td>—<tt>RX:ANY</tt>→</td> 418 <td><tt>QueueConnectionCloseFrame()</tt><br/><tt>SendPackets()</tt></td> 419</tr> 420<tr> 421 <td>—<tt>CAN_SEND</tt>→</td> 422 <td><tt>SendPackets()</tt></td> 423</tr> 424<tr> 425 <td rowspan="1"><tt>TERMINATING.DRAINING</tt></td> 426 <td rowspan="1"></td> 427 <td></td> 428 <td></td> 429</tr> 430<tr> 431 <td rowspan="1"><tt>TERMINATED</tt></td> 432 <td rowspan="1"></td> 433 <td>[terminal state]</td> 434 <td></td> 435</tr> 436</table> 437 438Notes on various events: 439 440- `CAN_SEND` is raised when transmission of packets has been unblocked after previously 441 having been blocked. There are broadly two reasons why transmission of packets 442 may not have been possible: 443 444 - Due to OS buffers or network-side write BIOs being full; 445 - Due to limits imposed by the chosen congestion controller. 446 447 `CAN_SEND` is expected to be raised due to a timeout prescribed by the 448 congestion controller or in response to poll(2) or similar notifications, as 449 abstracted by the BIO system and how the application has chosen to notify 450 libssl of network I/O readiness. 451 452 It is generally implied that processing of a packet as mentioned above 453 may cause new packets to be queued and sent, so this is not listed 454 explicitly in the Transition column except for the `CAN_SEND` event. 455 456- `PROBE_TIMEOUT` is raised after the PTO interval and stimulates generation 457 of a tail loss probe. 458 459- `IDLE_TIMEOUT` is raised after the connection idle timeout expires. 460 Note that the loss detector only makes a determination of loss due to an 461 incoming ACK frame; if a peer becomes totally unresponsive, this is the only 462 mechanism available to terminate the connection (other than the local 463 application choosing to close it). 464 465- `RX:STATELESS_RESET` indicates receipt of a stateless reset, but note 466 that it is not guaranteed that we are able to recognise a stateless reset 467 that we receive, thus this event may not always be raised. 468 469- `RX:ANY[CONNECTION_CLOSE]` denotes a `CONNECTION_CLOSE` frame received 470 in any non-discarded EL. 471 472- Any circumstance where `RX:RETRY` or `RX:VER_NEG` are not explicitly 473 listed means that these packets are not allowed and will be ignored. 474 475- Protocol errors, etc. can be handled identically to `APP:CLOSE` events 476 as indicated in the above table if locally initiated. Protocol errors 477 signalled by the peer are handled as `RX:ANY[CONNECTION_CLOSE]` events. 478 479Notes on various actions: 480 481- `SendPackets()` sends packets if we have anything pending for transmission, 482 and only to the extent we are able to with regards to congestion control and 483 available BIO buffer space, etc. 484 485Non-FSM Model 486------------- 487 488Common QUIC implementations appear to prefer modelling connection state as a set 489of flags rather than as a FSM. It can be observed above that there is a fair 490degree of commonality between many states. This has been modelled above using 491hierarchical states with default handlers for common events. [The state machine 492can be viewed as a diagram here (large 493image).](./images/connection-state-machine.png) 494 495We transpose the above table to sort by events rather than states, to discern 496the following list of events: 497 498- `APP:CONNECT`: Supported in `IDLE` state only. 499 500- `RX:VER_NEG`: Handled in `ESTABLISHING.PROACTIVE_VER_NEG` and 501 `ESTABLISHING.INITIAL_EXCHANGE_A` only, otherwise ignored. 502 503- `RX:RETRY`: Handled in `ESTABLISHING.INITIAL_EXCHANGE_A` only. 504 505- `PROBE_TIMEOUT`: Applicable to `OPEN` and all (non-ε) `ESTABLISHING` 506 substates. Handled via `SendProbeIfAnySentPktsUnacked()` except in the 507 `ESTABLISHING.PROACTIVE_VER_NEG` state, which reenters that state to trigger 508 retransmission of a Version Negotiation packet. 509 510- `IDLE_TIMEOUT`: Applicable to `OPEN` and all (non-ε) `ESTABLISHING` substates. 511 Action: immediate transition to `TERMINATED` (no `CONNECTION_CLOSE` frame 512 is sent). 513 514- `TERMINATING_TIMEOUT`: Timeout used by the `TERMINATING` state only. 515 516- `CAN_SEND`: Applicable to `OPEN` and all (non-ε) `ESTABLISHING` 517 substates, as well as `TERMINATING.CLOSING`. 518 Action: `SendPackets()`. 519 520- `RX:STATELESS_RESET`: Applicable to all `ESTABLISHING` and `OPEN` states and 521 the `TERMINATING.CLOSING` substate. 522 Always causes a direct transition to `TERMINATED`. 523 524- `APP:CLOSE`: Supported in `IDLE`, `ESTABLISHING` and `OPEN` states. 525 (Reasonably a no-op in `TERMINATING` or `TERMINATED.`) 526 527- `RX:ANY[CONNECTION_CLOSE]`: Supported in all `ESTABLISHING` and `OPEN` states, 528 as well as in `TERMINATING.CLOSING`. Transition to `TERMINATING.DRAINING`. 529 530- `RX:INITIAL`, `RX:HANDSHAKE`, `RX:1RTT`: Our willingness to process these is 531 modelled on whether we have an EL provisioned or discarded, etc.; thus 532 this does not require modelling as additional state. 533 534 Once we successfully decrypt a Handshake packet, we stop processing Initial 535 packets and discard the Initial EL, as required by RFC. 536 537- `TLS:HAVE_EL(HANDSHAKE)`: Emitted by the handshake layer when Handshake EL 538 keys are available. 539 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 543 confirmed, is reasonably implemented as a flag. 544 545From here we can discern state dependence of different events: 546 547 - `APP:CONNECT`: Need to know if application has invoked this event yet, 548 as if so it is invalid. 549 550 State: Boolean: Connection initiated? 551 552 - `RX:VER_NEG`: Only valid if we have not yet received any successfully 553 processed encrypted packet from the server. 554 555 - `RX:RETRY`: Only valid if we have sent an Initial packet to the server, 556 have not yet received any successfully processed encrypted packet 557 from the server, and have not previously been asked to do a Retry as 558 part of this connection (and the Retry Integrity Token validates). 559 560 Action: Note that we are now acting on a retry and start again. 561 Do not reset packet numbers. The original CIDs used for the first 562 connection attempt must be noted for later authentication in 563 the QUIC Transport Parameters. 564 565 State: Boolean: Retry requested? 566 567 State: CID: Original SCID, DCID. 568 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 571 still in Proactive Version Negotiation and should retransmit the Version 572 Negotiation packet we sent. 573 574 State: Boolean: Doing proactive version negotiation? 575 576 - `IDLE_TIMEOUT`: Only applicable in `ACTIVE` states. 577 578 We are `ACTIVE` if a connection has been initiated (see `APP:CONNECT`) and 579 we are not in `TERMINATING` or `TERMINATED`. 580 581 - `TERMINATING_TIMEOUT`: Timer used in `TERMINATING` state only. 582 583 - `CAN_SEND`: Stimulates transmission of packets. 584 585 - `RX:STATELESS_RESET`: Always handled unless we are in `TERMINATED`. 586 587 - `APP:CLOSE`: Usually causes a transition to `TERMINATING.CLOSING`. 588 589 - `RX:INITIAL`, `RX:HANDSHAKE`, `RX:1RTT`: Willingness to process 590 these is implicit in whether we currently have the applicable EL 591 provisioned. 592 593 - `TLS:HAVE_EL(HANDSHAKE)`: Handled by the handshake layer 594 and forwarded to the record layer to provision keys. 595 596 - `TLS:HANDSHAKE_COMPLETE`: Should be noted as a flag and notification 597 provided to various components. 598 599We choose to model the CSM's state as follows: 600 601 - The `IDLE`, `ACTIVE`, `TERMINATING.CLOSED`, `TERMINATING.DRAINED` and 602 `TERMINATED` states are modelled explicitly as a state variable. However, 603 the substates of `ACTIVE` are not explicitly modelled. 604 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? 612 613 - The following timers are modelled: 614 - PTO Timeout 615 - Terminating Timeout 616 - Idle Timeout 617 618Implementation Plan 619------------------- 620 621- Phase 1: “Steady state only” model which jumps to the `ACTIVE.OPEN` 622 state with a hardcoded key. 623 624 Test plan: Currently uncertain, to be determined. 625 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” 628 a ClientHello, a 0x02 byte “represents” a ServerHello. Keys are fixed. 629 630 Test plan: If feasible, an existing QUIC implementation will be modified to 631 use this protocol and E2E testing will be performed against it. (This 632 can probably be done quickly but an alternate plan may be required if 633 the effort needed turns out be excessive.) 634 635- Phase 3: Final model with TLS 1.3 handshake layer fully plumbed in. 636 637 Test plan: Testing against real world implementations. 638
