Module replay_window 

Bitmap-based sliding-window replay detection (RFC 4303 § 3.4.3 / IPsec ESP).

Per-stream replay protection for the data plane. Tracks the highest accepted sequence number plus a 1024-bit bitmap covering [high - 1024 + 1, high], rejecting duplicates and out-of-window-old packets.

Why this exists if the AEAD already prevents replay

The current AEAD construction (per-direction monotonic AtomicU64 counter folded into the nonce) cryptographically rejects replays — a duplicated packet carries an old counter, so the receiver-derived nonce no longer matches and decryption fails. This module is defense in depth:

• Catches the replay before AEAD work (saves CPU under attack).
• Yields an explicit, observable ReplayDetected error variant for metrics.
• Survives future AEAD redesigns (e.g. moving the nonce derivation off the strict counter onto header.sequence to support out-of-order delivery).

Window semantics

• WINDOW_BITS = 1024. Bit 0 represents high_watermark; bit i represents high_watermark - i.
• Sequence numbers strictly greater than high_watermark advance the window (left-shift the bitmap, mark bit 0).
• Sequence numbers within the window: check the bit; reject if set, accept and set the bit otherwise.
• Sequence numbers below high_watermark - WINDOW_BITS + 1: too old, reject.

The struct is small (128-byte bitmap + a couple of u32 words) and intended to be held per-stream under a parking_lot::Mutex.

Structs

ReplayWindow

Sliding-window replay tracker for a single sequence-numbered stream.

Constants

WINDOW_BITS

Width of the sliding window in bits. 1024 matches RFC 4303’s recommended upper bound and gives us comfortable headroom for severely reordered transports.