We apply a sliding window on received packets, to reject replay of old nonces while allowing for some small amount of reordering on the wire. ts_tunnel tracks the last 192 received packets (3 u64s per established session of overhead), whereas the reference implementation tracks 8128 packets (127 u64s per session).
The spec doesn't mandate any particular replay window size. ts_tunnel's was chosen to reduce the memory cost of established sessions relative to wireguard-go, but it may be too aggressively low for real networks. This is easily tunable in future either way, so we may just ignore it for now, but filing so we can triage properly.
We apply a sliding window on received packets, to reject replay of old nonces while allowing for some small amount of reordering on the wire. ts_tunnel tracks the last 192 received packets (3 u64s per established session of overhead), whereas the reference implementation tracks 8128 packets (127 u64s per session).
The spec doesn't mandate any particular replay window size. ts_tunnel's was chosen to reduce the memory cost of established sessions relative to wireguard-go, but it may be too aggressively low for real networks. This is easily tunable in future either way, so we may just ignore it for now, but filing so we can triage properly.