Re: quic protection against replayed packets

Jānis Čoders <janis.coders@gmail.com> Thu, 07 June 2018 06:33 UTC

Return-Path: <janis.coders@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C69B2130E7C for <quic@ietfa.amsl.com>; Wed, 6 Jun 2018 23:33:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.72
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HamMn1o-MAEj for <quic@ietfa.amsl.com>; Wed, 6 Jun 2018 23:33:50 -0700 (PDT)
Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1281D12777C for <quic@ietf.org>; Wed, 6 Jun 2018 23:33:50 -0700 (PDT)
Received: by mail-oi0-x22b.google.com with SMTP id c128-v6so7572912oig.11 for <quic@ietf.org>; Wed, 06 Jun 2018 23:33:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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: <500105a3-ce68-682f-638c-8ef88b19207e@huitema.net>
References: <CA+tEvRTTyOove9pTfcUx3Z-B1G96Gz960ts4vC4cirx=yJTPxQ@mail.gmail.com> <CAN1APdfioOBXQZTP-ELspW4O-WK1eB5RtwwgHduUijoFnTXkMw@mail.gmail.com> <500105a3-ce68-682f-638c-8ef88b19207e@huitema.net>
From: =?UTF-8?B?SsSBbmlzIMSMb2RlcnM=?= <janis.coders@gmail.com>
Date: Thu, 7 Jun 2018 09:33:48 +0300
Message-ID: <CA+tEvRT=J31un_wzD5hf+8eWBjzAL_yJG8JKePwjy=qNaxmLZA@mail.gmail.com>
Subject: Re: quic protection against replayed packets
To: Christian Huitema <huitema@huitema.net>
Cc: QUIC WG <quic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/YNStaS2AecqpgAWdUGApdGIAcKA>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=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 <huitema@huitema.net> 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