IETF Logo Mail Archive

Re: [quicwg/base-drafts] Optimistic ACK in early handshake (#2192)

MikkelFJ <notifications@github.com> Wed, 19 December 2018 10:44 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD0E130DEF for <quic-issues@ietfa.amsl.com>; Wed, 19 Dec 2018 02:44:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.065
X-Spam-Level:
X-Spam-Status: No, score=-8.065 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 mKqbPgPN8Bj0 for <quic-issues@ietfa.amsl.com>; Wed, 19 Dec 2018 02:44:05 -0800 (PST)
Received: from out-3.smtp.github.com (out-3.smtp.github.com [192.30.252.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8868B1277D2 for <quic-issues@ietf.org>; Wed, 19 Dec 2018 02:44:05 -0800 (PST)
Date: Wed, 19 Dec 2018 02:44:04 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1545216244; bh=XVw/zAL74q+G77dWvSvILs8RfmEgoI0IFF+xHRcAWJo=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=H5W3u7Es+TVyA2KidoMhJ/jNlR4yqeD+jGPZK/X1izo7u1EPmpirj6ZOckWWDzGF/ hz71p/e5z5htpc+2BFThavRvVVP/Bv9xVHrraMJ0gGlj5mulTNeWWmkvUepZ1ehFcy UlkuTbHSVjguVyCs5oL+uzzG7IiIhCYW1boh04V8=
From: MikkelFJ <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abd4f959308fdb0eb66aa303bd0f60abd57761639d92cf000000011831e2f492a169ce1753c928@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2192/448550411@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2192@github.com>
References: <quicwg/base-drafts/issues/2192@github.com>
Subject: Re: [quicwg/base-drafts] Optimistic ACK in early handshake (#2192)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c1a20f426b86_1c783ffb69ed45b4720ee"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mikkelfj
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/hLh7j7_RruUZd6uqyx9rRB9-iUg>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Dec 2018 10:44:08 -0000

Optimistic ACKs are an attack, not something permitted. But it also isn't renege as I understand the word since it ACK's something that was never send as opposed to regretting ACK'ing something earlier ACK'ed. The attack can cause a client to get all the bandwidth that a server intended to be shared across many clients.

To defend against optimistic ACK's, QUIC explicitly states that a connection should be closed if it sees an ACK on a packet that wasn't sent (at least for as long as packets are still tracked and can affect the congestion window). The problem is that this defence can be exploited by another attack which is an injection attack. And the defence against this injection attack would be to not defend against optimistic ACKs, at least while the injection attack is possible.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2192#issuecomment-448550411

v2.23.0 | Report a Bug | By Email