Package io.github.mahmoudimus.quic.token
package io.github.mahmoudimus.quic.token
Address validation tokens (RFC 9000 section 8.1), ported from quinn-proto's
token.rs and
bloom_token_log.rs: Retry and NEW_TOKEN tokens sealed with AES-256-GCM under a key the
server holds (TokenKey), their validation with expiry
and address binding (TokenValidator), and a bounded
replay log (BloomTokenLog); on the client, where
NEW_TOKEN tokens wait for the next connection (TokenStore,
TokenMemoryCache).-
ClassDescriptionA
TokenLogof bounded memory.What the token in a client's first Initial packet establishes.An address validation token: a payload and a random nonce.The server's secret for sealing address validation tokens, as quinn does it: an HKDF-SHA256 pseudorandom key from a master key, from which each token derives a one-time AES-256-GCM key using its random nonce as the HKDF info.Limits the reuse of NEW_TOKEN tokens, which attackers could replay to use the server as an amplifier (RFC 9000 section 8.1.4).A bounded, in-memoryTokenStore: up to a number of server names, each with a queue of up to a number of tokens.What an address validation token says, encrypted so that only the server can read it.A token sent in a Retry packet (RFC 9000 section 8.1.2), bound to the client's address and port, and short-lived since the client returns it at once.A token sent in a NEW_TOKEN frame (RFC 9000 section 8.1.3), for a later connection.Where a client keeps the address validation tokens servers send in NEW_TOKEN frames (RFC 9000 section 8.1.3), by server name, to present in the first Initial of a later connection so the server can skip its Retry round trip.Issues and checks a server's address validation tokens (RFC 9000 section 8.1): Retry tokens, bound to the client's address and port and valid forretryTokenLifetime, and NEW_TOKEN tokens, bound to its IP address, valid forvalidationTokenLifetimeand logged against reuse.