Re: quic protection against replayed packets

Mikkel Fahnøe Jørgensen <> Wed, 06 June 2018 21:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AC105130DE5 for <>; Wed, 6 Jun 2018 14:32:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NoVtuPxBmFE3 for <>; Wed, 6 Jun 2018 14:32:33 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 551AA130DD3 for <>; Wed, 6 Jun 2018 14:32:33 -0700 (PDT)
Received: by with SMTP id u4-v6so10168772itg.0 for <>; Wed, 06 Jun 2018 14:32:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=j4VHMoJHYCQWFtoMqKiPlUqU+j1EFADMwsM8AEf19y4=; b=uIBdofcP5tG1l8hcNt/luC/V2FlXgHJI+D54LBVi5pEpOToGEfrK5gz0HYCmy63DjG tUSGycxjvdFO62NJDHLo9f1r1xha7RxRTo71J9+gdDvCrGiwTaVz+eU14siIaXPwQdJo 7QOFPfQS1jW+EORNuYFOxPtZm3hYuvPvI2DhA1UcXg3XNyi0LCWuE3qVLI53qPRCBQCd ALBmskrz5BSc8sEA37P2IC5p9S8Pj7w5M3f4Gaa3ZpVScVLH7hMdHs0fqQT6Hpd/nxrB 1uC0FeE8kb2tuASeCA/PlSwbYYeDtIFTfLSpsE99psEpgOcxkNLaojdmY9/sBnhUq9Sy 9JEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=j4VHMoJHYCQWFtoMqKiPlUqU+j1EFADMwsM8AEf19y4=; b=Gk5ou1P5ek7AS6ViXiKGy/Ol+lZZWMCe2xnNmri3+FqLUD2F9Xhl5adomRcnskP5/A tKnv4+ZadxEW2huD5S5v6yn5nK91aOxcjVfPbQolgRqmdAcGmFcVjEswFlwe/Po56DWI 6S1kVt+gGsg7VOXqR5OjcwrZb/ez6gKHe43wlh3z9/FkBwyyc4npAfqsTqnUqVyL4Xj9 H3XeErwfZa9/+Ffsr1TuvL0yw7/NsuSuIcVhJhnBIe5JYo7TLam0D3nYmQYl2viq1J0J 3Yh0NnOF1OYtrftVVwFZWYdvd6CNGXLMcl7CBK43E9HfzO0Lexueb3phwosW4W9crVFh zffA==
X-Gm-Message-State: APt69E0vzrI2rxDqwYNVJ4VjoC38qoqW3wYxCy8hrMLwfqYPG99UkM0P rR39duVmddNwB0WUvqH6niGGYtEMViSrWbX6hIA=
X-Google-Smtp-Source: ADUXVKIJzDmk5u3wpoihMM4rqDf40U3C2viEfP7jCKPq6p38SHtSK5xE4yKXmolLoo/xZ3AdNSB5eomykko6LKZ4P8g=
X-Received: by 2002:a24:dbd6:: with SMTP id c205-v6mr4661255itg.118.1528320752754; Wed, 06 Jun 2018 14:32:32 -0700 (PDT)
Received: from 1058052472880 named unknown by with HTTPREST; Wed, 6 Jun 2018 14:32:31 -0700
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= <>
In-Reply-To: <>
References: <>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Wed, 6 Jun 2018 14:32:31 -0700
Message-ID: <>
Subject: Re: quic protection against replayed packets
To: =?UTF-8?B?SsSBbmlzIMSMb2RlcnM=?= <>, QUIC WG <>
Content-Type: multipart/alternative; boundary="0000000000009238dc056dffe7a4"
Archived-At: <>
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 06 Jun 2018 21:32:35 -0000

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 ( 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?