You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Brainstormed some ideas for anti-replay, and they're as follows;
Have a VecDeque with epoch and sequence information on the packets, plus their arrival time.
Have a "max age" parameter by which all older packets are discarded.
The first would be done with a 24-byte structure as;
pubstructPacketToken{epoch_seq:u64,// epoch and sequence in oneat:Instant,// u128 on linux, u64 on macos and windows}
This would discard anything older than 2 minutes, or FIFO at a max amount (configurable).
The oldest packet will update the "max age" sequence counter when it is popped from the stack, but only if it is younger than the age parameter.
Searching the VecDeque for a match when a packet comes in would introduce a little overhead, but at the cost of replay protection.
It would also cause a little memory overhead. (On linux, approximately 2.4MB for 100k packets indexed (150MB at max MTU, so 2 minutes of +10MBps download speeds))
The text was updated successfully, but these errors were encountered:
Brainstormed some ideas for anti-replay, and they're as follows;
The first would be done with a 24-byte structure as;
This would discard anything older than 2 minutes, or FIFO at a max amount (configurable).
The oldest packet will update the "max age" sequence counter when it is popped from the stack, but only if it is younger than the age parameter.
Searching the VecDeque for a match when a packet comes in would introduce a little overhead, but at the cost of replay protection.
It would also cause a little memory overhead. (On linux, approximately 2.4MB for 100k packets indexed (150MB at max MTU, so 2 minutes of +10MBps download speeds))
The text was updated successfully, but these errors were encountered: