Subject: quic protection against replayed packets

From: Jānis Čoders <[email-masked]>
Date: Wed, 6 Jun 2018 23:50:52 +0300

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?

--

---

From: Ian Swett <[email-masked]>
Date: Wed, 6 Jun 2018 17:22:28 -0400

If the packet was received recently, the receiver should just drop the
packet, because the same packet number was recently processed.

If it was a long time in the past, either the receiver will decide the
packet number is too low to process or it will process the packet and all
the frames it contains will be duplicates.

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Wed, 6 Jun 2018 14:32:31 -0700

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 ([email-masked]) wrote:

--

---

From: Christian Huitema <[email-masked]>
Date: Wed, 6 Jun 2018 15:45:25 -0700

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

> 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

---

From: Jānis Čoders <[email-masked]>
Date: Thu, 7 Jun 2018 09:33:48 +0300

Ok, so it means endpoints have to keep track of received packet
numbers. Just couldn't find that in standard.
At first I thought that all packets with lower PN than last valid must
be dropped, but then saw implementation where also lower packet
numbers are accepted

On 7 June 2018 at 01:45, Christian Huitema <[email-masked]> wrote:
> 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.
>
> 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

-- 
Ar cieņu,
Jānis Čoders

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 7 Jun 2018 09:35:58 +0200

Hi,

Yes, there is no text on this in the drafts.  There is an issue on this:

https://github.com/quicwg/base-drafts/issues/1405

/Magnus

-- 

Magnus Westerlund

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------