Configures the default clients and servers in proto tests to be able to
utilize NEW_TOKEN frames. This involves creating simple implementations
of token-related traits internal to the test module. These
implementations are essentially the most boring possible implementation
that is able to actually utilize tokens. They would not be suitable for
use in real applications because their memory usage is unbounded.
When we first added tests::util::IncomingConnectionBehavior, we opted to
use an enum instead of a callback because it seemed cleaner. However,
the number of variants have grown, and adding integration tests for
validation tokens from NEW_TOKEN frames threatens to make this logic
even more complicated. Moreover, there is another advantage to callbacks
we have not been exploiting: a stateful FnMut can assert that incoming
connection handling within a test follows a certain expected sequence
of Incoming properties.
As such, this commit replaces TestEndpoint.incoming_connection_behavior
with a handle_incoming callback, and modifies an existing test to
exploit this functionality to test more things than it was previously.
When a client receives a token from a NEW_TOKEN frame, it submits it to
a TokenStore object for storage. When an endpoint connects to a server,
it queries the TokenStore object for a token applicable to the server
name, and uses it if one is retrieved.
As of this commit, the only provided implementation of TokenStore is
NoneTokenStore, which is equivalent to the lack of a token store, and is
the default.
When a path becomes validated, the server may send the client NEW_TOKEN
frames. These may cause an Incoming to be validated.
- Adds TokenPayload::Validation variant
- Adds relevant configuration to ServerConfig
- Adds `TokenLog` object to server to mitigate token reuse
As of this commit, the only provided implementation of TokenLog is
NoneTokenLog, which is equivalent to the lack of a token log, and is the
default.
As of this commit, it only has a single variant, which is Retry.
However, the next commit will add an additional variant. In addition
to pure refactors, a discriminant byte is used when encoding.
The ability for the server to process tokens from NEW_TOKEN frames will
create the possibility of Incoming which are validated, but may still be
retried. This commit creates an API for that. This means that rather
than Incoming.remote_address_validated being tied to retry_src_cid, it
is tied to a new `validated: bool` of `IncomingToken`.
Currently, this field is initialized to true iff retry_src_cid is some.
However, subsequent commits will introduce the possibility for
divergence.
Previously, retry tokens were encrypted using the retry src cid as the
key derivation input. This has been described by a reputable individual
as "cheeky" (who, coincidentially, wrote that code in the first place).
More importantly, this presents obstacles to using NEW_TOKEN frames.
With this commit, tokens carry a random 128-bit value, which is used to
derive the key for encrypting the rest of the token.
Moves all the fields of Token to a new RetryTokenPayload struct, and
makes Token have a single `payload: RetryTokenPayload` field. This may
seem strange at first, but it sets up for the next commit, which adds
an additional field to Token.
dignifiedquire