msquic icon indicating copy to clipboard operation
msquic copied to clipboard

Support Async Resumption Ticket Validation

Open nibanks opened this issue 4 years ago • 0 comments

Describe the feature you'd like supported

Currently, the QUIC_CONNECTION_EVENT_RESUMPTION_TICKET_RECEIVED event assumes the app returns a success or failure inline. This is not ideal because there are scenarios where validation may require additional IO (network request to nonce server?) that can take time. So, to support these types of scenarios, the API should support a return of QUIC_STATUS_PENDING and completion of the validation at a later point in time.

Proposed solution

Unfortunately, the TLS layers (OpenSSL for sure at least) currently require immediate inline success/fail return. To support async at the QUIC/app layer we will have to work around this limitation. My proposal is that for success and pending returns from the app, we return success to TLS inline. If the app pended, then we pend the resulting CRYPTO payload until the app completes the validation. If the validation succeeds, we just continue as normal. The tricky part comes if they fail the validation (but not the connection). In this scenario, we will need to recreate the TLS state and reprocess the initial packet and then immediately fail the ticket validation. This shouldn't be too hard to pull off because we still have the received CRYPTO data cached from before.

nibanks avatar Apr 27 '21 17:04 nibanks