Re: quic protection against replayed packets

Jānis Čoders <> Thu, 07 June 2018 06:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C69B2130E7C for <>; Wed, 6 Jun 2018 23:33:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.72
X-Spam-Status: No, score=-1.72 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, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HamMn1o-MAEj for <>; Wed, 6 Jun 2018 23:33:50 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1281D12777C for <>; Wed, 6 Jun 2018 23:33:50 -0700 (PDT)
Received: by with SMTP id c128-v6so7572912oig.11 for <>; Wed, 06 Jun 2018 23:33:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Z5HyCHelwswn4yONllHgJT3q3irA4eRZStjz4X19c7Y=; b=KYFgnZ5xJOXHwGDt5DghIkG6nOWgvQLjrCcJXUvMU+XmqS3BpmGcKwJDn6mVQVsAL8 9aGx8oN0JG0RxlS4Ne0VA5A/2SD1z14+LhRIGLRXVxgOikFr23gVQPVfA7hSxPhqqrI+ 4Xzg8Ro7T8Joqh8qQZR5QKR6JhkrbbR3gW5tKc0xQ4Ddk2lyOrGDvjQZzsBGBY3CVJ/e V0zNhjXLey8+3I1smOOtr4HIao8fiYn2TOuygiqVJsiQn7KQgcI9KljHJ7iupAjvDP5S mM7obyFKBtTGgtGFNclbElzzKXwHRJhwvF1siY5PzKOqJjAcdRqsmsg6u/RSmxuPiEH6 f0HA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Z5HyCHelwswn4yONllHgJT3q3irA4eRZStjz4X19c7Y=; b=gnEUEYrzZ/RxPgdO70FFbzfXo8Y38SUntwfGRbN4qHnl8YxtGCfrcpXFExrkMNu6Sv ZoIobCwYeYFiADDbRmGDO1iS4xfLKkH8IndVtPazZuDAbgY0WTHiQO3fNGuJiizAsGa9 R63+hI3Vwg1NTaCbIedUEINGimGFYYdk3w6drVkH/QsPqwCwXb/ho4FReKkZ4GnKonBZ 6OP5bxI/ARWvfa8jjjim0TcmES5nfuedeor31udX2GJoMPk9xiZawocq4+l9km7p2+Sy aS88uPStwjIWaMjpDWHGE53iJcHhf7KzC4DjDktsaUDTZiVOGLJsv5SmQouy4qynBh1g 1vkg==
X-Gm-Message-State: APt69E25l/dyPW+vInq7kajJVhORYSb4X6tOqk1AZ8pmp5CImePnuHnq u+DMB5Un4esHTJBU4hdFlSuntno/+9fSG3ty/1o=
X-Google-Smtp-Source: ADUXVKI4qHXlRXKlFhYRpoA3r0R2B6Hg6K/e0KgQnqhLBubnU56FldOWCqaos7mCNaKNtRq8r23DJF8EXNPQ4RO9NPA=
X-Received: by 2002:aca:3e84:: with SMTP id l126-v6mr257202oia.231.1528353229190; Wed, 06 Jun 2018 23:33:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4a:414:0:0:0:0:0 with HTTP; Wed, 6 Jun 2018 23:33:48 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: =?UTF-8?B?SsSBbmlzIMSMb2RlcnM=?= <>
Date: Thu, 7 Jun 2018 09:33:48 +0300
Message-ID: <>
Subject: Re: quic protection against replayed packets
To: Christian Huitema <>
Cc: QUIC WG <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Thu, 07 Jun 2018 06:33:53 -0000

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

Ar cieņu,
Jānis Čoders