Re: quic protection against replayed packets

[Mikkel Fahnøe Jørgensen <[e-mail]>]

The first line of defence is that most implementations would filter
duplicate packets by tracking recently received packets, and dropping
anything with a packet number older than what is tracked.

Assuming duplicates are not filtered:

It depends on the packet content, or frame type more precisely. Some frames
deliver flow control credits or ACK’s and here the problem is not only
duplicates but also out of order delivery of same type of content in
different packets. Here flow control cannot be reduced, so out of date
content is ignored, and ACK’s cannot be unacked.

For stream frames, each stream keeps track of already received ranges. An
implementation could replace a range in the receive buffer with same
content which is harmless, or with different content (for retransmissions
done badly), but in either the case the application would (normally) only
see a single coherent range. QUIC must offer that view to the application,
but an implementation may expose more details and out of order ranges if so
desired, but that is outside the protocol.

If there is some frame type that does not sanely handle this, it is
probably a bug and an issue should be raised.

Note that 0-RTT is vulnerable to replays because connections can be
repeated. This is not possible in 1-RTT.

On 6 June 2018 at 22.51.16, Jānis Čoders ([e-mail]) wrote:

Hi, I am following QUIC development and there is one aspect I can't
find answer to - how does QUIC protect itself if attacker
replays/duplicates 1-RTT protected packets?
What should happen when repeated packet is received, because it will
be decrypted correctly. Should endpoints maintain some sort of
received packets window? Or are all the QUIC Frame types resistant
against duplicates?


--