Tested Build
005aa88
Observation
We observed that mvfst appears to decrypt and process packets even when a packet with the same packet number in the same packet number space was already processed. In our tests, replaying an already accepted packet results in the packet being decrypted again and the frames being processed again. While the logical outcome is idempotent, this behavior can still impose unnecessary CPU work. Is there a reason mvfst is implemented this way?
Expected Behavior
RFC 9000, Section 12.3 states:
A receiver MUST discard a newly unprotected packet unless it is certain that it has not processed another packet with the same packet number from the same packet number space. Duplicate suppression MUST happen after removing packet protection for the reasons described in Section 9.5 of [QUIC-TLS].
Tested Build
005aa88
Observation
We observed that mvfst appears to decrypt and process packets even when a packet with the same packet number in the same packet number space was already processed. In our tests, replaying an already accepted packet results in the packet being decrypted again and the frames being processed again. While the logical outcome is idempotent, this behavior can still impose unnecessary CPU work. Is there a reason mvfst is implemented this way?
Expected Behavior
RFC 9000, Section 12.3 states: