Expand description
Per-peer monotonic sequence counters and a 64-entry sliding-window replay detector.
§Outbound: PeerSeqSender
Each local-node-to-peer direction has a distinct counter. Sent frames
carry strictly-increasing sequence numbers starting from 1. 0 is
reserved as a sentinel meaning “never sent”.
§Inbound: PeerSeqWindow
A 64-bit bitmap anchored at last_accepted_seq. Frame with sequence
n is:
- accepted and window advanced if
n > last_accepted_seq - accepted and bit set if
last_accepted_seq - 63 <= n < last_accepted_seqand the bit was previously unset - rejected as replay if the bit was already set, or if
nis older than the window
The window model is identical to IPsec AH/ESP (RFC 4303 §3.4.3).
64 entries is the standard default — large enough that legitimate
reordering in-flight (rare over one QUIC stream but possible across
QUIC streams) is tolerated, and small enough to fit in a single
u64.
Structs§
- Peer
SeqSender - Outbound monotonic counter for this
AuthContext. One counter total — not one per target — because the receiver’s replay window is keyed by the sender’slocal_node_id. If this sender used a per-target counter, two distinct targets’ traffic would share the same window on any node that receives from both: seq=1 from target=A and seq=1 from target=B collide in the receiver’swindow[sender_id]. A single counter makes every outbound seq globally unique per sender. - Peer
SeqWindow - Per-peer inbound sliding-window replay detector. One window per (local_node, remote_peer) pair.
Constants§
- REPLAY_
WINDOW - Size of the inbound replay-detection window.