Re: quic protection against replayed packets

[Christian Huitema <[e-mail]>]

On 6/6/2018 2:32 PM, Mikkel Fahnøe Jørgensen wrote:

> 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.

The packet number filed only contains the lower bits of the packet
sequence number -- 32, 14 or 6 bits depending on encoding. The higher
order bits are filled up based on currently expected value. The
completed 64 bit number (62 bit really) is then used as part of the
initialization vector when decrypting the packet. If a very old packet
is replayed, the receiver fill guess the high order bits wrong, the
decryption will fail, and the packet will be rejected.

If the packet is relatively recent, then most implementations rely on
packet tracking to detect that this packet is not expected. The tracking
data is the same data as the "dashboard" that is needed to implement the
selective ack process. So in practice, one way or another, the duplicate
packet will be ignored.

The threat analysis envisages a different attack: intercept a packet,
suppress the original transmission, and resend the same packet from a
different address. This is one of the reasons why the migration
specification includes a challenge/response mechanism.


>
> 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.

Frames can be repeated, not because of a replay attack but because of
"spurious retransmission", which can happen for a variety of reasons. So
yes, applications have to be able to tolerate that and not break.

-- Christian Huitema