Re: quic protection against replayed packets

[Magnus Westerlund <[e-mail]>]

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


Den 2018-06-07 kl. 08:33, skrev Jānis Čoders:
> 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 <[e-mail]> wrote:
>> 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
>
>

-- 

Magnus Westerlund

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------