iroh_quinn

Trait TokenLog

Source 
pub trait TokenLog: Send + Sync {
    // Required method
    fn check_and_insert(
        &self,
        nonce: u128,
        issued: SystemTime,
        lifetime: Duration,
    ) -> Result<(), TokenReuseError>;
}
Expand description

Responsible for limiting clients’ ability to reuse validation tokens

RFC 9000 § 8.1.4:

Attackers could replay tokens to use servers as amplifiers in DDoS attacks. To protect against such attacks, servers MUST ensure that replay of tokens is prevented or limited. Servers SHOULD ensure that tokens sent in Retry packets are only accepted for a short time, as they are returned immediately by clients. Tokens that are provided in NEW_TOKEN frames (Section 19.7) need to be valid for longer but SHOULD NOT be accepted multiple times. Servers are encouraged to allow tokens to be used only once, if possible; tokens MAY include additional information about clients to further narrow applicability or reuse.

TokenLog pertains only to tokens provided in NEW_TOKEN frames.

Required Methods§

Source

fn check_and_insert( &self, nonce: u128, issued: SystemTime, lifetime: Duration, ) -> Result<(), TokenReuseError>

Record that the token was used and, ideally, return a token reuse error if the token may have been already used previously

False negatives and false positives are both permissible. Called when a client uses an address validation token.

Parameters:

  • nonce: A server-generated random unique value for the token.
  • issued: The time the server issued the token.
  • lifetime: The expiration time of address validation tokens sent via NEW_TOKEN frames, as configured by ServerValidationTokenConfig::lifetime.
§Security & Performance

To the extent that it is possible to repeatedly trigger false negatives (returning Ok for a token which has been reused), an attacker could use the server to perform amplification attacks. The QUIC specification requires that this be limited, if not prevented fully.

A false positive (returning Err for a token which has never been used) is not a security vulnerability; it is permissible for a TokenLog to always return Err. A false positive causes the token to be ignored, which may cause the transmission of some 0.5-RTT data to be delayed until the handshake completes, if a sufficient amount of 0.5-RTT data it sent.

Implementors§